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Abstract 

This  paper  examines  the  management  of  spares  acquisi¬ 
tion  and  logistics  support  activities  for  the  Air  Launched 
Cruise  Missi le  <ALCM>  engine.  A  SIMSCRIPT  21.3  simulation 
model  of  the  ALCM  system  is  developed  and  the  probable 
ranges  of  five  relevant  factors  (transportation  time,  main¬ 
tenance  duration,  engine  failure  rate,  test  duration  and 
test  loss  rate)  are  determined.  The  model  is  manipulated 
using  a  factorial  design  with  the  five  factors  at  the  ex¬ 
tremes  of  their  ranges.  An  ANGMA  is  used  to  determine  if 
changes  in  these  five  factors  significantly  impact  the  oper¬ 
ational  capability  of  the  ALCM  engine.  This  capability  is 
expressed  as  the  average  number  of  days  an  engine  must  be 
used  as  an  operational  asset  past  the  manufacturer's  war¬ 
ranty  period  without  an  overhaul.  The  AN OVA  indicated  that 
changes  in  transportation  time  and  maintenance  duration  had 
a  significant  effect  on  the  operational  capability  of  the 
ALCM  engine  and  thus  required  further  investigation  to  re¬ 
fine  their  range  of  values. 

The  model's  operation,  verification,  input  requirements 
and  output  capabilities  were  documented  so  that  the  model 
could  be  used  as  a  management  tool  when  validation  is  com¬ 
pleted.  This  documentation  will  give  other  modelers  the 


depth  of  understanding  necessary  to  adapt  the  model  to  their 
particular  use.  The  model  was  designed  with  the  flexibility 
necessary  to  modify  the  assumptions  and  limitations  built 
into  it  so  the  model  could  agrowB  as  the  ALCM  system 
evolves. 

ALCM  engine  managers  should  eventually  be  able  to  use 
the  model  to  test  the  effects  (on  a  number  of  variables  of 
interest)  of  changes  in  maintenance  policies  and  timing. 
The  model  should  easily  be  adaptable  to  reflect  the  environ¬ 
ment  of  the  Ground  Launched  Cruise  Missile  and  the  Submarine 
Launched  Cruise  Missile  systems.  It  could  then  be  used  to 
estimate  the  number  of  spare  engines  required  in  these 
systems  to  meet  various  engine  capability  levels  and  other 
management  goals. 
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A  SIMULATION  MODEL  FOR 

AIR  LAUNCHED  CRUISE  MISSILE  ENGINE  MANAGEMENT 


I.  Introduction  and  Background 


General  Issue 


The  management  of  spares  acquisition  and  logistics  sup¬ 
port  efforts  is  a  very  important  part  o-f  the  procurement  and 
future  viability  of  any  weapon  system.  Acquisition  and 
support  decisions  significantly  impact  both  system  costs  and 
weapon  system  capabilities.  Acquisition  costs  have  increased 
to  the  extent  that  repairable  spares  contracts  frequently 
involve  many  millions  of  dollars.  These  high  costs  make  it 
imperative  to  determine  a  total  system  support  concept  that 
provides  the  required  system  capabilities  while  controlling 
spares  acquisition  costs.  However,  modern  weapon  systems 
are  becoming  more  and  more  complicated,  making  the  develop¬ 
ment  of  a  viable  support  concept  more  difficult.  A  greater 
understanding  of  the  system's  operational  environment  and 
maintenance  requirements  is  needed  as  system  complexity 
increases. 

The  Air  Launched  Cruise  Missile  <ALCM)  is  one  of  a 
family  of  three  similar  missiles  that  are  currently  (or  soon 
will  be)  employed  by  all  three  branches  of  the  armed  ser¬ 
vices.  Like  most  weapon  systems,  many  of  the  ALCM's  parts 


can  be  repaired  i-f  broken  and  require  routine  servicing  at 
specified  time  intervals.  During  the  time  these  parts  are 
being  repairedf  spare  parts  must  be  available  to  replace 
them  to  keep  the  number  of  deployed  missiles  at  a  specified 
level.  For  major  repairable  spare  parts,  such  as  the  engine 
assemblies  that  this  paper  considers,  it  is  important  to 
find  out  how  many  spares  will  be  required  over  the  life  of 
the  system  before  the  original  production  line  is  closed 
down.  This  is  the  life-of-type  procurement  strategy  for 
special  item  procurements  as  authorized  by  Air  Force 
Logistics  Command  <AFLC)  regulations  (  1:1-3).  If  too  few 
engines  are  procured,  the  number  of  operational  missiles 
will  <at  some  point)  fall  below  the  specified  level  or  the 
production  line  will  have  to  be  opened  up  again  <at  con¬ 
siderable  expense)  to  produce  more  spares.  If  too  many 
engines  are  procured,  large  amounts  of  money  will  have  to  be 
spent  unnecessarily.  Effective  and  economic  system  support, 
including  the  storage,  distribution  and  maintenance  of  these 
spare  engines  is  just  as  critical  as  the  correct  number  of 
spares  in  providing  the  required  system  capabilities.  Thus 
the  effects  of  engine  failure  rates,  maintenance  duration 
and  frequency,  transportation  time,  and  testing  requirements 
on  system  capabilities  must  be  considered  as  well  as  the 
number  of  spares. 

The  responsibilities  for  managing  acquisition  programs 
are  directed  by  Air  Force  Regulation  800-2,  Acquisition 
Program  Management  <  5).  The  weapon  system  acquisition 
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process  is  managed  through  a  Systems  Program  Office  (SPO> 


and  guided  by  a  Program  Management  Plan  (PMP) .  A  SPO  has 
latitude  in  developing  an  effective  plan  for  the  particular 
system. 

A  program  manager  involved  in  production  planning 
is  frequently  faced  with  a  high  degree  of  uncer¬ 
tainty  surrounding  both  the  timing  and  the  quan¬ 
tity  of  the  requirements  for  his  particular  system 
or  subsystem.  .  It  is  advantageous  for  the 
program  manager  to  consider  a  wide  range  of  feas¬ 
ible  alternatives  in  order  to  structure  a  produc¬ 
tion  plan  adaptable  to  changing  conditions 
<4: 50) . 

Current  methods  used  to  determine  the  quantity  of  spares 
to  purchase  for  a  weapon  system  during  acquisition  are 
governed  by  Department  of  Defense  Instruction  (D ODD  4140.42 
<  6)  .  This  instruction  encourages  the  use  of  operational 
demand  data  as  the  primary  source  of  input  to  determine  the 
level  of  spares  required.  DODI  4140.42  "allows  for  sparing 
of  essential  items  that  do  not  meet  the  demand  criteria 
(and).  .  .  sparing  by  alternative  computational  techniques 
which  minimize  system  downtime  (14il4).a  But  providing  for 
alternatives  does  not  create  valid  techniques.  "The  major 
criticism  in  the  inventory/suppl y  area  for  military  appli¬ 
cation  is  the  lack  of  attention  to  objectives  that  emphasize 
weapon  systems  availability  and  capability  (  7:13)."  But  a 
comprehensive  spares  management  methodology  for  the  ALCM 
engine  program  does  not  exist.  One  of  the  major  difficul¬ 
ties  in  devising  a  methodology  that  considers  weapon  system 
availability,  along  with  engine  requirements,  is  the  lack  of 
demand  data.  Since  this  is  the  initial  deployment  of  the 
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ALCM,  a  data  base  has  not  boon  established.  The  models 
developed  for  00D  use  a  demand  data  base  for  requirements 
determination,  and  are  not  suited  for  this  problem. 

Thus  one  sees  that  the  current  analytical  methods  used 
to  forecast  demand  for  repairable  spares  and  to  determine 
the  impact  of  different  support  concepts  do  not  apply 
directly  to  the  ALCM  engine  system.  The  complexity  and 
multiplicity  of  factors  bearing  on  the  problem  make  it 
difficult  enough  to  even  conceptualize  the  system,  much  less 
to  apply  mathematical ly  tractable  analytical  techniques  to 
it.  As  Emory  says, 

.  .  there  are  many  processes  for  which  there  is 
no  analytical  solution,  or  at  least  not  one  at¬ 
tainable  at  a  reasonable  cost.  Often  the  pro¬ 
cesses  are  so  complex  as  to  defy  analytical  so¬ 
lution  with  the  present  state  of  the  art.  It  is 
in  these  cases  that  simulation  has  the  advantage 
<8:355) . 

For  these  reasons  a  simulation  model  will  be  used  to  examine 
the  logistics  requirements  for  the  ALCM  engine. 

A  simulation  model  can  be  used  to  assist  the  manager  in 
examining  and  understanding  the  system  under  study  and  in 
determining  the  significant  relationships  which  should  be 
included  in  planning  for  overall  system  support.  A  model 
provides  a  cost  effective  means  of  considering  numerous 
feasible  alternatives  to  complex  acquisition  and  logistics 
management  situations  <17:11).  Models  record  the  important 
elements  of  a  system,  providing  the  manager  with  a  tool  with 
which  to  objectively  view  the  parts  and  their  interactions. 
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A  model  aids  the  basic  decision  process  and  helps  a  manager 
determine  the  spares  level  and  support  requirements  to  use. 
Drezner  and  Hillestad  in  their  report  titled  ■ Logistics 


Models:  Evolution  and  Future  Trends"  state: 

There  should  be  more  effective  use  of  good  support 
models  in  the  ongoing  management  of  logistics.  Me 
must  move  from  the  bean  counting  approach  of  cur¬ 
rent  readiness  reporting  to  using  models  to  pre¬ 
dict  force  capability  to  go  to  war  <  7:29). 

Even  if  there  is  no  past  demand  data  with  which  to  work,  a 
simulation  model  can  be  a  good  tool  in  understanding  future 
system  requirements,  if  the  model  is  a  good  representation 
of  the  actual  system.  A  limit  to  the  capabilities  of  simu¬ 
lation  is  expressed  by  Emory  : 

He  can  not  identify  the  optimal  answer  to  this 
problem  with  a  simulation.  However,  if  we  rerun 
the  simulation  a  number  of  times  with  different 
.  .  .  strategies,  we  can  identify  the  best  of  the 
strategies  that  we  test  (  8:361) . 

The  value  of  this  tool  depends  on  the  validity  of  the  as¬ 
sumptions  made  about  the  system  and  how  accurately  the  model 
has  captured  the  important  relationships  between  the  deter¬ 
mining  variables  in  the  system. 


Spec i f i c  Probl em 

The  Air  Launched  Cruise  Missile  (ALCM)  is  now  being 
deployed  as  an  operational  missile  at  various  bases.  ALCM 
system  managers  need  information  of  the  effects  on  ALCM 
operational  capabilities  of  1)  the  number  of  spare  engines 
procured  2)  maintenance  and  testing  policies  3)  engine 


failure  rates  and  4)  transportation  times.  A  need  exists 
for  a  model  that  will  estimate  the  effects  on  ALCti  opera¬ 
tional  capabilities  of  the  number  of  spare  engines  procured 
and  the  logistics  policies  used  to  manage  them.  The  model 
must  be  documented  as  to  its  assumptions  and  the  signifi¬ 
cance  of  its  output.  Information  as  to  which  parameters 

* 

could  be  adjusted  to  reflect  more  current  information  must 

be  incorporated  in  this  documentation.  As  Shannon  states: 

No  simulation  project  can  be  considered  success¬ 
fully  completed  until  it  has  been  accepted,  under¬ 
stood,  and  used.  .  .  .  Careful  and  complete 

documentation  of  the  development  and  operation  of 
the  model  can  greatly  increase  its  useful  life  and 
chances  of  successful  implementation  (17:32-33). 

The  model  must  reflect  the  random  nature  of  many  of  the 

factors  from  which  it  will  be  derived,  and  validity  must  be 

established  for  its  proposed  application.  Documentation 

and  validation  will  provide  information  on  how  management 

should  treat  the  model's  output  (how  management  might  best 

use  the  information  the  model  develops)  and  the  confidence 

management  should  have  in  this  output. 

System  Overview 

Figure  1  is  a  diagram  of  the  ALCM  system  showing  the 
major  factors  that  impact  system  support  requirements  for 
spare  engines.  Spare  engines  are  required  to  fill  the 
transportation  pipeline  of  repaired  engines  between  the 
depot  and  operating  base,  broken  engines  being  shipped 
to  the  depot,  and  those  engines  being  shipped  for  periodic 


Figure  1. 


System  Diagram 


depot  maintenance  <21:14,20).  Spare  engines  are  also  re¬ 
quired  during  the  time  the  engines  are  undergoing  depot 
maintenance  or  planned  modifications.  Finally,  every  now 
weapon  system  undergoes  acceptance  and  improvement  tests  -for 
many  years  after  initial  deployment  <20> .  These  tests  are 
usually  run  on  systems  or  components  which  are  part  of 
operational  stocks.  For  the  ALCM,  engines  at  operational 
bases  are  selected  for  testing,  transported  to  the  test 
location,  and  then  undergo  one  of  several  performance  tests. 
One  of  these  tests  will  require  a  spare  engine  to  replace 
the  test  engine  taken  from  the  operating  base. 

The  Williams  International  plant  manufactures  ALCM 
engines  and  provides  these  engines  to  the  Boeing  facility 
where  they  are  mated  with  airframes,  the  production  process 
is  completed,  and  the  missile  shipped  to  the  operating  base. 
In  addition  to  these  engines,  Williams  will  provide  a  speci¬ 
fied  number  of  spare  engines  to  be  used  in  the  ALCM  system. 
Williams  will  also  perform  primary  depot  level  repair  and 
scheduled  maintenance  on  the  engines  (which  is  time-phased) . 
Each  engine  is  warranted  for  a  certain  time  period  after  its 
original  date  of  manufacture  and  after  each  subsequent  over¬ 
haul  .  The  extent  of  depot  maintenance  is  determined  by  the 
type  of  engine  <F 107- 101  or  F 107- 104)  and  the  phase  of 
maintenance  due  (limited  or  full).  After  the  first  warranty 
period  has  elapsed,  the  engine  will  be  due  a  limited  over¬ 
haul.  After  the  second  warranty  period,  it  will  be  due  a 
full  overhaul,  then  the  cycle  repeats  itself. 


Refurbishment  is  another  type  of  overhaul  don*  at 


Mil  Hams  to  r*turn  an  *ngin*  us*d  in  tasting  to  a  service¬ 
able  condition.  A  final  servicing  category  is  the  conver¬ 
sion  from  the  F 107- 101  type  engine  currently  being  produced 
to  a  F 107- 104  type  to  provide  more  power  and  extend  the 
engine's  warranted  service  life.  This  type-conversion  will 
take  place  from  1988  to  1992  at  the  Hilliams  International 
depot  facility.  The  alternate  engine  repair  and  servicing 
facility  (depot),  at  Oklahoma  City  Air  Logistics  Center 
(OCALC) ,  is  scheduled  to  begin  operations  in  1989.  This 
facility  will  perform  limited  overhauls  only. 

The  deployment  bases  are  where  the  missiles  are  sche¬ 
duled  to  be  in  operational  use.  Missiles  will  initially  be 
transported  from  the  assembly  plant  at  Boeing  to  the  opera¬ 
tional  bases.  Once  a  missile  Arrives  on  a  base,  it  is  used 
as  an  operational  asset s  in  storage,  on  alert,  etc  .  The 
engine's  warranted  life  <30  months  for  a  F 107- 101  or  60 
months  for  a  F107-104)  begins  when  it  is  delivered  to  the 
Boeing  plant  for  missile  assembly  and  ends  30  or  60  months 
after  this  date.  This  warranted  life  is  renewed  upon  com¬ 
pletion  of  depot  servicing  and,  again,  ends  30  or  60  months 
after  this  date.  The  engine  will  be  removed  from  the  mis¬ 
sile  for  overhaul  when  its  warranted  life  has  expired  and  a 
spar*  engine  is  available  to  replace  it.  If  an  earlier 
requirement  for  an  engine  exists  to  smooth  the  depot  work 
flow,  an  engine  may  be  removed  before  its  warranted  lifetime 
has  expired.  Although  warranted  for  the  length  of  time 
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cited  Above,  the  engine  may  -fail  prematurely  and  require 


Q 


% 


replacement.  All  engines  in  which  a  -failure  is  detected 
will  be  removed  -from  alert  duty  and  replaced  as  soon  as  a 
spare  engine  is  available.  Engines  selected  for  testing 
will  also  be  removed  when  a  spare  is  available.  Complete 
missiles  selected  for  testing  will  not  require  a  spare 
engine,  and  will  be  returned  to  their  respective  bases  after 
ref urbishment .  Engines  removed  for  failure  or  warrantee 
expiration  are  sent  back  to  the  depot  for  overhaul,  while 
those  removed  for  testing,  along  with  selected  test  mis¬ 
siles,  are  sent  to  the  appropriate  test  facility. 

The  test  types  includes  Engine  Verification  and  Im¬ 
provement  Program  (EVIP)  -  a  non-destructive  test  on  a  re¬ 
moved  engine,  Operational  Test  Launches  (OTL>  -  a  free 
flight  test  of  a  complete  missile  with  a  planned  midair 
recapture  (there  is  a  possibility  of  the  missile  not  being 
recaptured  and  thus  being  destroyed  in  this  test) ,  and  Joint 
Test  Assembly  (JTA)  -  a  free  flight  test  of  a  complete 
missile  resulting  in  missile  destruction.  The  OTL  test 
keeps  a  complete  missile  unavailable  for  the  duration  of  the 
test.  The  EVIP  test  keeps  only  the  missile's  engine  un¬ 
available  for  the  duration  of  the  test.  After  testing,  each 
engine  or  surviving  missile  is  sent  to  the  depot  for  refur¬ 
bishment,  and  then  redistributed  as  a  spare  engine  or  a 
replacement  missile.  The  exclusion  of  the  Production 
Assurance  Test  (performed  on  engines  prior  to  their 
assembly),  will  not  affect  the  model's  validity.  An  excess 


’  o  o  o  > 


of  engines  over  air-frames  exists  and  will  continue  to  exist , 
so  the  test  will  not  delay  missile  availability. 

Research  Obj ectives 

The  objectives  o-f  this  research  include  t  1>  A  thorough 
review  o-f  the  ALCM  spare  engine  system  to  determine  the 
system's  relevant  variables  and  their  interrelationships! 
and  the  amount  and  type  o-f  variability  in  these  relation¬ 
ships.  2)  Building  a  computer  simulation  model  o-f  the 
system  will  then  be  developed  to  re-flect  these  -findings.  3) 
Experimenting  with  the  model  to  assess  the  significance  of 
changes  in  these  variables  on  the  system's  operational  capa¬ 
bility.  4)  Documenting  the  derivation,  use,  applicability 
and  significance  of  the  model's  output.  .  9>  Incorporating 
flexibility  into  the  model's  design  to  allow  for  changes 
that  will  invariably  occur  with  increased  knowledge  of  the 
real  system.  This  flexibility  must  also  allow  the  assess¬ 
ment  of  changes  to  system  variables  not  addressed  in  this 
research,  and  make  the  model  adaptable  to  changes  in  manage¬ 
ment  perspective. 

ftt-Mfrqh  Question 

A  final  objective  of  this  research  is  to  answer  three 
specific  research  questions:  Do  any  of  the  selected  vari¬ 
ables  <see  factor  variability  pages  19-22)  have  a  signifi¬ 
cant  effect  on  the  ALCM  engine  operational  capability  when 


allowed  to  vary  within  their  probable  range  of  values? 
Which  o-f  the  variables  are  signi-f icant?  What  are  the  impli¬ 
cations  o-f  these  -findings?  ALCM  engine  operational  cap¬ 
ability  is  the  overall  probability  o-f  a  given  missile's 
engine  successfully  -firing  and  operating  as  designed  when  a 
demand  is  placed  on  it.  This  capability  assumes  the  system 
is  able  to  maintain  a  specified  (classified)  number  of 
operational  missiles  at  all  times.  For  this  research,  en¬ 
gine  operational  capability  will  be  expressed  in  terms  of 
the  average  time  <in  days)  that  an  engine's  operational  life 
(usage  after  manufacturing  or  depot  servicing)  exceeds  its 
warranted  service  life.  This  operational  definition  assumes 
a  decrease  in  the  probability  of  firing  when  an  engine 
exceeds  its  warranted  life.  The  particular  relationship 
between  engine  life  and  probability  of  firing  on  demand  is 
not  known  at  this  time.  Due  to  the  limited  time  and  re¬ 
sources  available  for  this  research,  this  relationship  will 
not  be  addressed  in  this  paper,  though  this  relationship 
would  provide  a  great  deal  of  useful  information.  This 
paper  will  assume  that  management  can  use  the  stated  measure 
as  a  viable  proxy  for  the  overall  probability  of  an  engine 
firing  and  operating  successfully. 

Limi tations  and  Scope 

Some  factors  exist  in  the  ALCM  system  that  will  not  be 
examined  in  this  model,  therefore  the  model  will  be 


developed  with  the  -following  assumptions.  Exceeding  the 
engine's  warranted  life  increases  the  probability  of  an 
engine  not  firing  on  demand.  The  engine's  warranted  service 
life  and  its  probability  of  premature  failure  is  independent 
of  the  type  service  it  sees  (storage,  alert  duty,  captive 
flight,  etc.),  which  is  a  reflection  of  the  missile's  use. 
The  engine  will  never  be  used,  run  up  or  tested  at  base 
level  unless  it  is  actually  engaged  against  a  target,  and  at 
that  time,  is  unrecoverabl e  (20). 

Once  an  engine  is  determined  to  be  destined  for  de¬ 
structive  testing,  it  is  considered  out  of  the  system  at 
that  time.  Nhen  a  missile  is  selected  for  testing,  all  the 
various  test  procedures  will  be  considered  as  one  factor. 
Thus  the  model  will  not  reflect  the  individual  variables  at 
a  t#st  site,  but  will  consolidate  them  into  one  variable, 
the  average  time  required  to  accomplish  the  test. 

The  same  is  true  of  the  depot  level  maintenance  func¬ 
tion,  the  relevant  factor  in  this  model  being  the  time  an 
engine  spends  in  the  depot,  in  total,  not  the  actual  process 
it  goes  through  while  at  the  depot.  Furthermore,  all  spare 
engines,  except  those  destructively  tested,  can  be  renewed 
indefinitely  (  with  appropriate  servicing  to  "as  good  as 
new"  condition).  That  is,  once  an  engine  is  produced,  it  is 
always  a  potential  spare  resource.  In  addition  ,  each  depot 
is  considered  to  have  an  unlimited  servicing  capacity  (each 
depot  can  service  an  unlimited  number  of  engines  at  the  same 


time)  (20) 


This  model  will  be  designed,  however,  with  the  -flexibil¬ 
ity  necessary  to  modify  assumptions  and  limitations,  and 
insert  newly  discovered  relevant  variables  or  different 
levels  of  factors,  as  management  may  see  fit,  at  any  time  in 
the  future.  Since  "every  model  is  based  upon  certain  as¬ 
sumptions  regarding  an  uncertain  -future  which  the  model  is 
supposed  to  organize  and  eventually  predict  .  .  .  <16:293)", 
the  model  must  be  able  to  be  changed  when  the  assumptions 
change  or  are  proved  invalid. 

The  main  thrust  of  this  model  will  be  to  give  management 
a  tool  to  both  understand  the  ALCM  system  and  to  determine 
the  significance  that  changes  in  selected  variables  have  on 
system  capabilities.  Those  variables  found  to  have  a  signi¬ 
ficant  impact  on  system  capabilities  can  be  investigated  in 
depth  to  determine  their  actual  range  of  variability.  Con¬ 
trol  efforts  can  then  be  directed  toward  these  factors, 
reducing  the  emphasis  placed  on  those  which  do  not  affect 
system  capabilities.  This  will  allow  managers  to  expend 
their  resources  where  they  will  be  the  most  productive.  In 
addition,  the  model  will  be  constructed  to  allow  forecasts 
of  the  monthly  demand  for  spare  engines,  and  monthly  re¬ 
quirements  for  the  five  types  of  depot  servicing.  It  will 
also  be  able  to  estimate  the  effects  of  various  maintenance, 


test,  and  transportation  scenarios  on  system  capability. 
The  model  will  have  the  flexibility  to  improve  with  age  (and 
better  data)  for  increasingly  accurate  forecasts. 
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1 1 .  Methodol  oc 


The  methodology  that  will  be  used  in  this  research  is  an 
expansion  o-f  the  Systems  Science  Paradigm  as  expressed  by 
Schoderbek,  et  al  ,  which  is  an  "application  o-f  the  systems 
approach  to  the  study  o-f  real-world  phenomena  <  16:293-384)  ■ . 
The  System  Science  Paradigm  consists  o-f  three  successive 
phases:  Conceptualization,  Analysis  and  Measurement,  and 
Computerization . 


Conceptual ize  the  Problem 


The  -first  step  will  be  the  conceptualization  o-f  the 

problem,  de-fined  by  Schoderbek,  et  al  .  as 

understanding  and  organizing  the  interactions 
among  the  elements  making  up  the  phenomenon  under 
scrutiny  into  a  logical  network  of  relationships 
in  such  a  way  as  to  reveal  the  direction  of  the 
underlying  structure  <16:290). 

The  purpose  of  the  system  being  modeled  must  be  thoroughly 
understood.  Then  the  modeler  can  clearly  state  the  objec¬ 
tive  of  his  or  her  study.  The  variables  which  interact 
within  the  system,  and  between  the  system  and  its  environ¬ 
ment,  must  be  examined.  The  model  should  include  only  those 
independent  variables  determined  to  be  relevant  to  the  ac¬ 
complishment  of  the  stated  objectives.  The  model  should  be 
structured  to  permit  the  measurement  of  the  dependent  vari¬ 
ables  to  determine  whether-  or  not  the  stated  objectives  have 
been  met  < 16)  . 
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TABLE  I 


_ ENGINE  PRODUCTION  SCHEDULE _ 

YEAR  JAN  FEB  MAR  APR  MAY  JUN  JUL  AUG  SEP  OCT  NOV  DEC 


1981 

0 

0 

0 

0 

0 

6 

8 

8 

12 

12 

14 

17 

1982 

22 

24 

28 

32 

35 

40 

48 

40 

40 

40 

40 

48 

1983 

40 

40 

40 

40 

40 

41 

39 

40 

40 

40 

40 

40 

1984 

40 

47 

47 

26 

35 

27 

28 

27 

28 

27 

28 

27 

1985 

27 

27 

23 

30 

21 

16 

17 

19 

20 

20 

20 

20 

198  4 

-  28 

28 

_2I_ 

24 

_ L_ 

0 

0 

0 

0 

0 

8 

0 

TABLE  II 


MISSILE  PRODUCTION 


YEAR  JAN  FEB  MAR  APR  MAY  JUN  JUL  AUG  SEP  OCT  NOU  PEC 


1981 

0 

0 

0 

0 

8 

0 

0 

0 

0 

0 

2 

3 

1982 

7 

9 

12 

13 

18 

22 

28 

32 

35 

40 

40 

40 

1983 

40 

40 

40 

40 

40 

48 

40 

40 

40 

40 

37 

37 

1984 

37 

36 

37 

36 

36 

36 

36 

36 

36 

40 

28 

28 

1985 

28 

28 

28 

28 

27 

27 

27 

27 

27 

27 

20 

20 

1994. 

..  29 

28 

_2S_ 

28 

28 

28 

28 

28 

2fi_ 

_2i_ 

_9_ 

_ g_ 

Data  Col  1  get ion .  The  background  information  used  to 
describe  the  ALCM  system  as  wall  as  a  detailed  description 
of  variables  in  the  system  were  provided  by  the  Engine 
Logistics  Office  of  the  Aeronautical  Systems  Division  (ASD) 
at  Wr ight-Pat ter son  AFB,  Ohio  <20> .  ASD  provided  a  regular 
engine  production  schedule  for  the  Williams  plant,  which 
began  in  June  1981  and  extends  through  April  1986.  This 
schedule  is  depicted  in  Table  I,  which  shows  the  number  of 
engines  produced  per  month  over  this  five  year  period.  A 
total  of  1713  F187-101  engines  will  be  produced  during  this 
period.  Table  II  shows  the  missile  production  schedule. 


This  schedule  depicts  the  number  of  complete  missiles 


< engine  end  airframe)  assembled  end  deployed  per  month  from 
November  1981  to  October  1986. 


A  decision  was  made  in  January  of  1984  to  procure  US 
spare  F 107- 101  engines  for  the  ALCM  system.  The  spare 
engines  were  produced  at  the  Williams  production  facility 
from  January  1982  to  December  1983  concurrently  with  the 
regular  engine  production  run. 


TABLE  111 


— 

Days 

past  1 

January  1981 

570 

1311 

1887 

2463 

3039 

3687 

4263 

4839 

5415 

770 

1347 

1923 

2499 

3075 

3723 

4299 

4875 

5475 

810 

1383 

1959 

2535 

3111 

3759 

4335 

4911 

5520 

850 

1419 

1995 

2571 

3147 

3795 

4371 

4947 

5565 

890 

1455 

2031 

2607 

3183 

383  i 

4407 

4983 

5610 

930 

1491 

2067 

2643 

3219 

3867 

4443 

5019 

5655 

970 

1527 

2103 

2679 

3255 

3903 

4479 

5055 

5700 

1010 

1563 

2139 

2715 

3291 

3939 

4515 

5091 

5745 

1050 

1599 

2175 

2751 

3363 

3975 

4551 

5127 

3799 

1090 

1635 

2211 

2787 

3399 

4011 

4587 

5163 

5835 

1095 

1671 

2247 

2823 

3471 

4047 

4623 

5199 

1131 

1707 

2283 

2859 

3507 

4083 

4659 

5235 

1167 

1743 

2319 

2895 

3543 

4119 

4695 

5271 

1203 

1779 

2355 

2931 

3579 

4155 

4731 

5307 

1239 

1815 

2391 

2967 

3615 

4191 

4767 

5343 

12Z5 

2427 

3003 

3651 

WLYrTM 

Tables  III  through  V  show  representative  schedules  for 
the  various  tests  to  be  performed  on  engines  and  complete 
missiles  beginning  in  1982  and  continuing  into  1996  (in 
days  past  1  January  1981).  These  tests  will  be  conducted  in 
the  year  they  are  scheduled,  though  the  specific  dates  will 


TABLE  IV 


1 _ OTL  TEST  SCHEDULE _ 

Days 

past  1 

January  1981 

545 

1365 

1860 

2310 

2795 

3235 

3675 

4150 

4745 

730 

1410 

1905 

2355 

2835 

3275 

3715 

4195 

4866 

803 

1455 

1950 

2400 

2875 

3315 

3755 

4240 

4987 

876 

1500 

1995 

2445 

2915 

3355 

3795 

4285 

5108 

949 

1545 

2040 

2490 

2955 

3395 

3835 

4330 

5229 

1022 

1590 

2085 

2555 

2995 

3435 

3875 

4380 

5350 

1095 

1635 

2130 

2595 

3035 

3475 

3915 

4440 

5471 

1140 

1680 

2175 

2635 

3075 

3515 

3955 

4500 

5592 

1185 

1725 

2200 

2675 

3115 

3555 

4015 

4560 

5713 

1275 

1770 

2220 

2715 

3155 

3595 

4060 

4620 

1815 

,-ffigS- 

4680 

TABLE  V 


JTA  TEST  SCHEDULE 


Days 

past  1 

January  1981 

730 

1168 

1642 

2097 

2676 

3402 

4128 

4854  5580 

803 

1241 

1690 

2188 

2797 

3523 

4249 

4975 

876 

1314 

1733 

2279 

2918 

3644 

4370 

5096 

949 

1387 

1824 

2370 

3039 

3765 

4491 

5217 

1022 

1460 

1915 

2461 

3160 

3886 

4612 

5338 

1095 

1551 

2006 

2555 

4007 

4733 

Table  VI  shows  a  proposed  schedule  (developed  by  the 
authors)  of  engine  type  conversions  (F107-101  to  F 107- 104) . 
This  is  the  modification  of  the  original  engine  to  the 
upgraded  version.  This  schedule  is  based  on  the  attempt  to 
modify  the  maximum  number  of  engines  possible  during  their 
regularly  scheduled  "full"  overhaul,  given  the  constraints 
of  380  modification  Kits  being  available  in  1788,  420  in 


1989.  510  in  1990,  and  568  in  1991.  This  schedule  is  based 


on  projected  overhaul  dates  stemming  -from  the  engines'  ini¬ 
tial  production  dates,  but  does  not  account  for  engine 
failures  earlier  than  the  warranted  time,  nor  for  cycle 
changes  caused  by  engine  testing.  It  attempts  to  minimize 
conversions  of  limited  overhauls  in  1988-1989  that  could  be 
converted  during  their  scheduled  full  overhauls  in  1990- 
1991.  Since  the  conversion  process  takes  the  same  amount  of 
time  as  a  full  overhaul,  but  two-to-five  times  as  long  as  a 
limited  overhaul,  this  schedule  would  tend  to  decrease  the 
total  time  engines  would  spend  in  the  depot  over  the  conver¬ 
sion  period. 

TABLE  VI 


NUMBER  OF  FULL  CONVERSIONS  ALLOWED 


21 

45 

45 

45 

45 

46 

0 

0 

0 

0 

0 

0 

0 

0 

0 

19 

35 

27 

28 

27 

28 

27 

0 

0 

28 

27 

0 

0 

21 

16 

17 

19 

20 

20 

20 

20 

2B 

20 

21 

26 

0 

_ 6 

_ 

_8_ 

12 

12 

14 

17 

OF 

LIMITED 

CONVERSIONS 

ALLOWED 

MAR 

APR 

m  * 

sUfiL 

SEP 

0 

0 

0 

0 

0 

0 

28 

27 

25 

30 

23 

0  l 

0 

0 

0 

0 

0 

0 

27 

29 

32 

37 

40 

44 

45 

45 

45 

45 

45 

43 

24 

0 

0 

0 

0 

0 

44 

45 

45 

45 

22 

43 _ 40 

47 

47 

7 

8 

0 

Factor  Var labi 1 i ty .  From  the  information  gathered  from 
ASD  during  the  initial  interview,  a  flow  model  was  developed 
by  the  authors.  This  model  depicted  the  flow  of  the  engines 
through  the  projected  ALCM  system  as  the  authors  initially 
conceptualized  it.  Subsequent  interviews  and  questions 


About  unci  oar  relationships  and  variable  values  hoi  pod  ro- 
fine  and  corroct  this  modol  .  Tho  ASD  porsonnol  validatod 
tho  final  flow  modol  as  an  accurato  rofl action  of  tho  system 
as  they  know  it.  Tho  final  model  depicted  five  variables 
which  appeared  to  have  the  potential  for  significant  impact 
on  ALCM  system  capabilities,  and  displayed  same  variability 
in  their  estimated  values. 

The  first  variable  was  the  transportation  time  required 
to  move  an  engine  between  the  depots  and  each  base  or  test 
facility,  and  the  transportation  time  required  to  move  an 
engine  between  a  base  and  the  test  facilities.  The  figure 
offered  as  the  'standard*  transpor tation  time  (a  maximum 
time  in  which  an  engine  should  arrive  at  its  destination)  by 
ASD/YZL  was  eight  days.  This  standard  time  does  not  account 
for  difference  in  transpor tation  distance,  mode,  or  possible 
expediting  actions.  The  shortest  time  considered  likely  was 
a  minimum  of  four  days  (20) .  The  difference  of  four  days 
may  seem  inconsequential.  However,  considering  the  total 
number  of  trips  to  be  made  ,  it  may  prove  significant  (1830 
engines  x  2  trips  per  45  months  during  20  years  of  system 
life  x  4  days  per  trip  »  87,840  days  of  transportation  time 
difference)  . 

The  second  variable  is  the  amount  of  time  required  to 
test  an  engine  or  missile.  Initial  estimates  indicated 
sixty  days  would  be  required,  but  later  tests  were  being 
completed  closer  to  forty  days  (20).  With  a  potential  20 


day  difference  and  a  total  of  235  EVIP  and  OTL  tests  to  be 
completed,  engines  may  be  tied  up  in  tests  4,700  days  less 
if  the  lower  -figure  is  true. 

The  third  variable  considered  is  the  loss  rate  for  OTL 
inflight  recoveries.  Initial  estimates  indicated  a  2SX  loss 
rate  for  OTL  tests,  but  crew  experience  and  improvament  in 
techniques  could  move  this  figure  closer  to  10J£  early  on 
<20) .  Since  OTL  missiles  do  not  require  spare  engines  there 
is  no  impact  on  the  number  of  spare  engines  required.  How¬ 
ever,  there  is  an  impact  on  the  competition  for  depot  ser¬ 
vices  and  the  future  demand  for  spare  engines  if  more  of  the 
OTL  missiles  are  recovered  than  expected. 

The  fourth  variable  is  the  amount  of  time  required  for 
depot  servicing.  the  contract  negotiated  with  Mil  Hams 
allows  a  thirty  day  period  for  limited  overhauls  and  a  sixty 
day  period  for  full  overhauls.  However,  investigation  of 
workcards  and  interviews  with  Hilliam's  supervisory  person¬ 
nel  by  ASD/Y2L  indicated  the  possible  completion  of  limited 
overhauls  in  as  few  as  six  days  and  full  overhauls  in  thirty 
days  <20) .  Tests  refurbishment,  broken  engine  repair,  and 
F107-101  to  F107-104  conversions  require  approximately  the 
same  range  of  operations  as  a  full  overhauls  and  thus  will 
take  approximately  the  same  amount  of  time.  The  difference 
between  these  two  estimates  amounts  to  approximately  400,000 
repair  days  over  a  20  year  period. 

The  fifth  and  final  variable  is  the  pramature  engine 
failure  rate  for  depl oyed  missi 1 es.  Estimated  by  ALCM 


21 


system  engineers  at  15K,  this  failure  rate  has  not  yet  been 
verified  by  test  results  <20> .  Even  if  1SX  is  a  valid 
figure  for  the  actual  failure  rate,  its  effect  on  the  demand 
for  spare  engines  may  not  approach  anywhere  near  this  fig¬ 
ure.  The  ALCM  engine  is  maintained  in  a  sealed  container 
during  storage,  and  even  when  installed  in  a  missile  air¬ 
frame,  a  failure  would  be  very  difficult  to  detect.  Since 
no  field  tests  for  proper  operation  are  conducted  at  the 
base  (which  would  involve  running  the  engine,  designed  es¬ 
sentially  for  one-time  use),  the  only  indication  of  a  fail¬ 
ure  is  by  visual,  external  inspection.  If  the  engine  is 
leaking  oil,  hydraulic  fluid,  or  physically  falls  apart,  the 
failure  could  be  detected.  Otherwise,  a  failed  engine  would 
rsmain  in  a  deployed  status  and  assumed  to  be  operational. 
The  undetected  failed  engine  would  not  require  a  replace¬ 
ment,  resulting  in  a  decreased  demand  for  spare  engines. 
This  would  effectively  reduce  the  failures  close  to  zero. 
The  distribution  of  time  before  failure  is  unknown  and  will 
be  assumed  to  be  uniform  over  the  engine's  warranted  life. 
Nith  an  average  loss  of  456  days  per  failed  missile,  a 
reduction  of  failures  from  15 V.  to  V7.  could  save  almost 
1,800,000  days  of  warranted  life  before  overhaul  over  a  20 
year  period. 

Factors  that  will  be  fixed  at  a  given  level  are  the 
warranted  life  for  the  F107-101  engine  <913  days)  and  the 
warranted  life  for  the  F107-104  engine  (1826  days).  The 
number  of  operational  bases  will  be  fixed  at  six, 


with  five 


bases  requiring  286  missiles  and  the  sixth  requiring  285 
missi 1 es. 


Analysis  and  Measurement 


In  the  analysis  and  measurement  step,  the  parameters 
(those  quantities  "to  which  the  operator  of  the  model  may 
assign  arbitrary  values  (17:15)")  o-f  the  model  are  deter¬ 
mined  and  a  parametric  model  is  built.  An  experimental 
design  is  developed  specifying  how  the  -factors  in  the  model 
are  manipulated  and  what  levels  o-f  the  -factors  are  studied. 
Finally,  the  criteria  used  (a  manager -researcher  perspec¬ 
tive)  to  Judge  the  significance  of  changes  in  the  model's 
output  is  stated. 

The  experimental  design  of  this  thesis  allowed  the  re¬ 
searchers  to  determine  which  factors  or  combination  of  fac¬ 
tors  significantly  affect  the  model's  response  measurement. 
By  isolating  the  factors  at  both  extremes  of  their  hypothe¬ 
sized  range,  the  changes  in  the  model  response  measurement 
attributed  to  changes  in  each  factor's  level  were  deter¬ 
mined.  Five  factors  were  considered  variable,  the  others 
were  considered  as  environmental  factors  or  fixed  inputs 
into  the  system.  For  the  initial  screening  of  these  fac¬ 
tors,  a  factorial  design  was  run,  varying  these  factors  at 
two  levels,  which  indicated  how  sensitive  the  model  was  to 
each  of  these  factors.  A  factorial  design  with  five  factors 
and  two  levels  required  thirty-two  replications  of  the 
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experiment.  The  -five  -factors  and  their  levels  for  each  of 
the  thirty- two  experimental  runs  are  shown  in  Table  VII.  An 
analysis  of  variance  (ANOVA)  was  run  on  these  data  points  to 
determine  the  significance  of  the  main  and  interaction  ef¬ 
fects  on  the  primary  system  measurement  <the  average  time  an 
engine  spends  in  an  operational  status  past  its  warranted 
lifetime).  The  significance  of  changes  in  the  dependent 
variable  were  examined  at  the  alpha  ■  .10,  .05  and  .01 
levels. 

Additional  information  on  system  performance  that  the 
model  can  produce  will  be  provided  in  Appendix  A:  Simulation 
Output  Summary.  No  formal  analysis  will  be  performed  on  the 
data  presented,  but  the  output  is  useful  in  seeing  the  type 
of  information  that  the  model  can  provide  to  system 
managers. 


Computeri zin< 


the  Model 


The  model  was  written  in  the  SIMSCRIPT  1 1. 5  simulation 
programming  language,  then  compiled  and  run  on  the  CDC  CYBER 
computer  system  at  Wri ght-Patterson  AFB,  Ohio.  There  are 
four  main  reasons  why  SIMSCRIPT  1 1. 5  was  chosen  as  the 
language  to  model  the  system.  1)  SIMSCRIPT  has  an  English 
like  syntax  which  simplifies  the  explanation  of  the  program 
to  managers  and  other  users  without  a  computer  programming 
background.  2)  SIMSCRIPT  has  more  capabilities  in  simulat¬ 
ing  systems  than  any  other  language  <17:140).  3)  Expertise 


in  SIMSCRIPT  was  available 


4)  SIMSCRIPT  allows  the  model- 
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ing  of  a  system  on  a  modular  basis.  It  allows  the  designing 
and  testing  o-f  each  module  -for  correct  operation  independent 
o-f  all  other  modules.  After  individual  testing,  all  the 
modules  can  be  combined  to  reflect  the  workings  o-f  the 
system  as  a  whole.  This  capability  is  very  important  when 
designing  models  o-f  complex  systems,  as  it  greatly  eases 
model  debugging  (finding  and  correcting  errors)  and 
verif ication. 

Model  Devel opment .  The  SIMSCRIPT  model  was  designed  to 
parallel  the  structure  of  the  ALCM  system  as  closely  as 
possible.  This  is  facilitated  by  the  use  of  the  simulation 
concepts  known  as  "sets",  'entities*,  "processes*  and 
"routines*,  and  by  control  of  these  concepts  by  the  "system" 
and  other  "awning"  entities  (see  Appendix  Bi  Glossary  of 
Selected  SIMSCRIPT  Terms).  The  model's  built  in  "system" 
controls  a  series  of  "sets"  which  serve  as  storage  facili¬ 
ties  for  a  given  class  of  "entities"  (the  spare  engines  and 
missiles  in  the  ALCM  system).  One  class  of  entities  may 
represent  engines  which  have  been  produced  by  Williams,  are 
stored  at  the  Boeing  facility,  and  have  not  yet  been  mated 
with  an  airframe.  Another  class  may  be  those  missiles  that 
are  operational  assets  at  a  certain  base.  Yet  another  class 
may  be  those  engines  that  have  failed  or  have  exceeded  their 
warranted  life  on  base  and  are  awaiting  a  spare  engine  to 
replace  them.  Sets  are  able  to  sequence  engines,  say,  into 
the  depot  for  repair,  based  on  a  set  of  priorities  that  the 
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system  has  established.  These  sets  are  also  able  to  perform 


a  variety  of  record  Keeping  functions,  such  as:  keeping 


tracK  of  how  many  engines  are  in  a  certain  class  at  any 


particular  time  (e.g.,  how  many  engines  are  currently  being 


tested),  which  particular  engines  are  in  a  given  class 


<e.g.,  is  engine  #  344  in  an  operational  missile  or  is  it 


removed  and  awaiting  repair  ?  >,  or  which  engine  of  a 


given  class  has  the  highest  priority  for  an  available  re¬ 


source  <e.g.,  which  engine  on  which  base  has  been  broken  the 


longest  ?  ) 


Besides  the  "system",  SIMSCRIPT  allows  the  model  to 


have  other  "owning"  entities.  An  example  that  parallels 


the  ALCM  system  is  the  two  depots  that  exist  in  this  model . 


Each  of  the  depots  in  the  model  own  a  set  (stockpile)  of 


repaired  engines  that  are  available  as  spare  resources.  The 


depots  process  demands  for  spare  engines,  select  the  oldest 


engine  available,  ship  the  engine  to  the  requesting  base, 


update  their  inventory  records,  and  inform  all  interested 


agencies  in  the  system  of  the  number  of  spare  engines  re¬ 


maining.  The  depot  also  informs  the  system  of  the  repair 


capability  it  has  remaining,  receives  and  queues  incoming 


engines  for  servicing,  examines  the  records  accompanying  the 


engine  to  determine  the  type  of  servicing  it  requires, 


services  the  engine  as  indicated,  updates  the  engine's  rec¬ 


ords,  and  stores  the  repaired  engine  in  its  stockpile. 


The  model  also  "creates"  the  required  number  of  opera¬ 


tional  "bases",  giving  them  sets  to  store  operational  mis- 


silts,  missiles  destined  for  testing,  and  engines  needing 
repair  or  scheduled  servicing.  The  base  monitors  the  status 
of  each  missile,  detecting  its  -failure  or  determining  its 
requirement  -for  scheduled  servicing.  It  then  requisitions  a 
spare  engine  if  needed,  or  arranges  -for  shipping  a  missile 
to  the  test  site.  The  base  receives  incoming  spare  engines, 
removes  and  replaces  the  old  engine,  ships  the  old  engine  to 
the  appropriate  depot  -for  servicing,  and  updates  the  records 
o-f  the  old  and  new  engines. 

The  ALCM  system's  engines  are  represented  in  the  model 
as  'temporary  entities'.  Each  entity  begins  its  existence 
when  created  by  an  engine  production  "process',  according  to 
a  production  schedule  read  into  the  model  -from  an  external 
-file.  Each  engine  carries  a  set  o-f  'attributes'  (its  own 
set  of  records)  that  indicate  a  variety  of  information,  such 
as:  the  date  it  was  produced  or  overhauled,  when  its  next 
servicing  is  due,  what  type  of  servicing  it  will  require, 
were  it  is  located,  its  identification  number,  its  prece¬ 
dence  for  resources  as  compared  to  other  engines  in  the  same 
class,  which  class(es)  it  belongs  to,  and  many  other  pieces 
of  information. 

The  system,  depots  and  bases  perform  their  various 
functions  and  make  decisions  by  the  use  of  different 
"processes".  Processes  are  actions  that  are  scheduled  to 
occur  by  the  system  at  various  times  and  under  various 
circumstances  or  combination  of  circumstances.  For  example, 
if  an  engine  at  an  operational  base  fails,  the  base  will 
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detect  this,  end  schedule  an  "engine  requisition"  process  to 


3 


occur.  The  requisition  process  will  examine  appropriate 
variables  in  the  system  to  determine  i-f  the  engine  has 
indeed  -failed,  a  spare  engine  is  available  to  replace  it, 
and  no  other  engine  has  a  higher  priority  for  replacement. 
If  the  appropriate  conditions  have  been  met,  the  requisition 
process  will  request  the  spare  engine  from  the  depot,  ar¬ 
range  for  transporting  the  spare  to  the  base  (via  a  "trans¬ 
portation  process")  and  schedule  an  "exchange  process"  to 
handle  the  engine  removal  and  replacement  when  the  spare 
engine  arrives  at  the  base. 

Processes  accomplish  these  actions  by  relying  on  pro¬ 
gramming  code  that  reflects  various  decision  rules  that  are 
examined  whenever  more  than  one  course  of  action  is  possi¬ 
ble.  These  decision  rules  are  based  on  the  assumptions  made 
about  the  ALCM  system  and  the  priorities  established  for 
resource  allocation.  These  rules  are  designed  to  parallel 
the  priorities,  policies,  and  decision  logic  that  exists  in 
the  actual  ALCM  system.  For  a  detailed  analysis  of  the 
decision  logic  built  into  the  model,  refer  to  Appendix  C: 
Model  Operation  and  Decision  Logic. 

Some  of  the  many  functions  that  processes  perform  in¬ 
clude:  manufacturing  engines  and  scheduling  their  delivery; 
gathering  statistics  on  the  variables  in  the  system;  deploy¬ 
ing  operational  missiles  to  bases;  scheduling  and  conducting 
tests;  scheduling  and  performing  preventive  maintenance, 
repairs,  and  modifications;  choosing  the  depot  and  engine  to 


be  used  for  -filling  a  requisition;  choosing  the  depot  to 
receive  and  service  each  engine;  and  selecting  engines  -for 
testing. 

Model  Construction .  Model  construction  began  with  the 
"creation"  of  the  physical  facilities  that  exist  in  the  ALCM 
system:  the  bases,  depots,  test  facilities,  engine  storage 
facilities,  etc.  These  facilities  were  then  given  the  capa¬ 
bility  to  receive,  classify,  process,  store,  and  monitor 
engines  <via  the  assignment  of  the  appropriate  sets  to  each 
facility).  Next,  processes  were  created  to  handle  all  the 
necessary  decision  making,  prioritization,  resource  alloca¬ 
tion,  record  keeping,  and  other  managemert.  functions. 

A  tree  diagram  was  then  developed  showing  all  the 
possible  paths  through  the  system  an  engine  could  take, 
under  all  combinations  of  circumstances.  The  processes  were 
given  decision  rules  to  follow  at  each  node  for  each  branch 
of  the  tree  an  engine  could  follow.  The  processes  were 
designed  to  examine  the  status  of  the  engine  (its  attri¬ 
butes),  the  applicable  variables  in  the  system,  the  re¬ 
sources  available,  the  priorities  in  effect  at  that  time, 
and  the  current  simulation  time  before  deciding  what  path 
the  engine  would  take  at  each  node. 

Processes  were  designed  to  apply  the  appropriate  proba- 
bi 1 i ty  for  path  selection  if  the  path  to  take  was  subject  to 
chance.  This  was  accomplished  by  sampling  from  a  built-in 
(SIMSCRIPT-suppl ied)  random  number  generator  and  applying 
the  results  to  the  appropriate  probability  distribution. 


Sets  and  engines  were  given  attributes,  continually 
updated  by  the  processes,  that  reflected  the  current  and 
cumulative  status  of  various  output  variables.  Routines 
were  designed  to  sample  the  values  of  these  attributes  and 
other  system  variables  at  appropriate  times  (continuously, 
daily,  monthly,  etc.),  accumulate  and  calculate  statictics 
on  these  values,  format  the  statistics,  and  print  them  to  an 
external  file  for  later  examination. 

Input  Data  Manipulation .  Schedules  and  variable  values 
were  designed  to  be  read  by  the  model  from  external  files 
prior  to  starting  the  simulation  (see  Appendix  Ds  Input 
Files  SIMU7  and  SIMU9,  and  Tables  I  through  VI )  Thus  the 
same  model  accepts  a  variety  of  input  parameter  values,  runs 
the  simulation  on  the  basis  of  these  values,  and  returns  a 
statistical  summary  of  the  simulation  to  external  files. 
Different  runs  are  easily  accomplished  with  the  same  model 
by  making  a  one  or  two  line  change  of  those  input  variables 
that  differ  from  one  simulation  run  to  the  next.  Each  run's 
output  is  directed  to  a  separate  output  file.  After  running 
all  the  variable  combinations  desired,  the  output  variables 
under  study  are  consolidated  into  one  file  that  is  used  as 
input  to  a  statistical  analysis  program. 

Program  Documentation .  The  SIMSCRIPT  program  developed 
in  the  research  effort  is  listed  in  Appendix  E:  Program 
Listing.  A  more  detailed  explanation  of  the  SIMSCRIPT  pro¬ 
gram  terms  is  contained  in  Appendix  F:  Explanation  of 
Program  Terms.  This  appendix  gives  a  description  of  each 
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variable's  usage,  an  overview  of  each  processes'  function, 
and  details  on  the  functions  of  the  model's  sets,  attributes 
and  entities.  Appendix  Ca  Model  Operation  and  Decision 
Logic,  examines  some  of  the  assumptions  made  in  developing 
the  model . 

Verification 

Model  verification  is  the  process  of  "insuring  that  the 
model  behaves  the  way  an  experimenter  intends  ( 17:39) To 
verify  this  model  the  following  procedures  were  used:  The 
flow  of  an  engine  through  the  model  was  traced  to  ensure 
that  the  intended  decision  logic  was  followed.  System  vari¬ 
ables  were  recorded  both  before  and  after  a  decision  point. 
The  variables  recorded  before  the  dejc  i  si  on  point  were  exa¬ 
mined  to  determine  what  decision  logic  should  be  followed  at 
that  point.  Then  the  variables  recorded  after  the  decision 
point  were  examined  to  determine  if  the  appropriate  decision 
logic  was  actually  followed.  This  procedure  was  repeated 
tracing  different  engines  until  all  possible  decision  logic 
had  been  verified  throughout  the  model.  An  example  of  this 
procedure  is  presented  in  Appendix  6:  Sample  Verification 
Process. 


Validation  "is  the  process  of  bringing  to  an  acceptable 
level  the  user's  confidence  that  any  inference  about  a 


The 


system  derived  -from  the  simulation  is  correct  <  17:29)  ". 
importance  of  model  validation  must  be  recognized.  The  use 
of  an  unvalidated  model  may  result  in  the  manager  placing 
his  trust  in  a  model  that,  though  verified  for  correct 
operation ,  may  not  adequately  capture  the  real  world  phe¬ 
nomena  and  relationships  it  is  designed  to  reflect.  The 
complete  validation  of  this  model  is  beyond  the  scope  of 
this  research.  Only  preliminary  validation  was  accomplished 
during  this  research  effort.  This  preliminary  validation 
consisted  of  an  informal  review  of  the  output  data  by  the 
office  of  ASO/YZL.  This  office  judged  the  model's  output  to 
be  a  reasonable  reflection  of  what  the  real-world  system 
would  generate,  based  upon  their  knowledge  of  the  system  at 
that  time.  The  authors  suggest  that  complete  validation 
occur  before  managers  give  full  weight  to  the  model's  out¬ 
put.  Since  there  is  no  current  data  on  which  to  base  this 
validation,  the  authors  suggest  that  the  expert  method  of 
validation  be  used.  This  involves  breaking  down  the  output 
at  different  stages,  and  letting  the  current  experts  on 
those  stages  pass  judgement  on  whether  or  not  the  model's 
output  reflects  the  output  they  would  expect  the  real-world 
system  to  generate.  If  not,  the  experts  should  assist  the 
modelers  in  determining  what  the  real  output  should  look 
like,  and  where  and  what  the  modelers  should  change  to 
better  capture  the  real  situation.  Model  verification  and 
validation  is  well  covered  in  the  literature  by  authors  such 
as  Berman  <2) ,  Garratt  <  9) ,  Gilmour  <  10)  ,  and  Nolan  < 13) . 


Analysis  and  Measurement 


The  previous  chapters  have  thoroughly  described  the 
operational  environment  o-f  the  ALCM  engine  system.  The 
authors  researched  the  system  through  the  Engine  Logistics 
Off  ice  o-f  the  Aeronautical  Systems  Division  <ASD/YZL> .  A 
conceptual  model  was  developed  -from  this  research  and  veri- 
-fied  -for  accuracy  by  this  o-f -f ice.  An  experimental  design 
was  developed  that  would  allow  the  modeler  to  test  the 
e-f-fects  o-f  changes  in  the  selected  independent  variables  on 
the  model's  dependent  variable!  the  average  number  o-f  days 
an  engine's  operational  life  exceeds  its  warranted  life.  A 
computer  model,  written  in  the  SIMSCRIPT  II. 9  programming 
language,  was  then  developed  and  verified.  This  model  re¬ 
flected  the  conceptual  model's  structure  and  was  capable  of 
monitoring  changes  in  the  dependent  variable  brought  about 
by  manipulations  of  the  independent  variables. 

An  Analysis  of  Variance  < AN OVA)  was  used  to  determine 
if  changes  in  the  independent  variables  significantly 
changed  the  dependent  variable.  The  AN OVA  analysis  of  the 
output  of  a  factorial  design  is  useful  in  that  all  the  main 
effects  and  interactions  of  the  independent  variables  can  be 
estimated  at  the  same  time  (12:3-19). 

One  of  the  benefits  derived  from  experimentation  with 
simulation  models  is  that  sampling  from  the  population  of  a 


model's  output  can  bo  manipulated  by  the  experimenter  "with¬ 
out  introducing  bias  in  the  response  of  interest 


This  is  done  by  using  Variance  Reduction  Techniques  (VRTs) , 
which  reduce  "the  variance  of  the  estimator  by  replacing  the 
original  sampling  procedure  by  a  new  procedure  which  yields 
the  same  expected  value  but  with  a  smaller  variance 
< lit  105)"  and  increase  the  "reliability  of  the  estimated 
response  of  a  particular  system  (11:208)". 

A  reduction  in  variance  for  this  analysis  was  obtained 
by  the  VRT  of  "Common  Random  Numbers”  (11:200-206).  This 
technique  uses  the  same  stream  of  random  numbers  for  each  of 
the  model's  stochastic  variables  from  run  to  run.  This 
procedure  results  in  a  series  of  correlated  dependent  re¬ 
sponse  variables.  In  investigating  the  effects  of  different 
levels  of  input  variables  on  the  output  response  variable, 
one  is  "not  interested  in  the  absolute  values  of  the  system 
responses  but  in  the  difference  among  system  responses 
(11:200)”.  Since  the  variance  for  the  difference  of  two 
responses,  x  and  y,  is  given  by  the  equation  Var(x-y)  * 
Var(x)  +  Var(y)  -  2  Cov(x,y),  any  increase  in  the  covari¬ 
ance  term  will  result  in  a  decrease  in  the  variance  for  the 
difference.  The  correlated  responses  obtained  in  this  re¬ 
search  result  in  a  positive  covariance  term  reducing  the 
variance  of  the  dependent  variable  (11:200).  The  correla¬ 
tion  of  observations  caused  by  common  random  numbers  vio¬ 
lates  the  assumption  of  independent  observations  normally 
required  for  an  ANOWA.  However,  the  t-test  is  considered 


robust  enough  to  indicate  signi-f icance  even  when  indepen¬ 
dence  assumptions  are  violated  <3> . 


Testim 


Measurements.  The  simulation  model  in  this  experiment 
was  run  thirty-two  times  using  all  possible  combinations  of 
input  variable  levels.  This  was  accomplished  by  using  dif¬ 
ferent  input  files  for  each  run  for  the  variable  factors, 
and  common  input  files  for  the  fixed  factors.  Examples  of 
these  files  are  shown  in  Appendix  D:  Input  Files  SIMU7  and 
S1MU9,  and  Tables  I  through  VI .  SIMU7  is  an  example  of  one 
of  the  combinations  of  input  variable  levels  depicted  in 


Table  VI Is  Variable  Factors. 


Table  VIII:  Simulation 


Output,  shows  the  response  value  of  the  dependent  variable 
observed  for  each  of  the  thirty-two  treatment  combinations 
run  on  the  model.  The  designators  A0/A1,  B0/B1,  C0/C1, 
D0/D1,  and  E0/E1  reflect  the  low  and  high  levels,  respec¬ 
tively,  of  the  independent  variables  shown  in  Table  VII. 

Method.  These  results  were  evaluated  by  ANOVA  using 
the  Yates'  Method  of  computing  factorial  effects  totals. 
This  method  is  the  "most  expeditious"  computational  method 
for  looking  at  multiple  factorial  effects  (3:158).  The 
effect  means  calculated  by  the  Yates'  Method  are  shown  in 
Table  IX.  The  lower  case  letters  <a-e>  in  the  left  hand 
column  of  Table  IX  indicate  which  variables  are  at  a  high 
level  in  that  treatment.  If  a  letter  is  not  present  in  a 
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treatment  its  corresponding  variable  was  set  low  -for  that 
run.  All  calculations  were  performed  with  the  full  number 
of  significant  digits  allowed  on  the  CDC  CYBER  computer 
system.  The  calculations  shown  in  Table  IX,  except  for  the 
treatment  results  and  effect  means,  have  been  rounded  to 
whole  numbers  for  readability. 


TABLE  IX 


>■/ 
,*•  .* 
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An  examination  of  this  data,  again  rounded  for  readability, 
revealed  negligible  effects  for  the  third  through  fifth 
order-interactions.  Thus  the  treatment  sum  of  squares  was 
calculated  on  the  main  effects  and  second-order  interactions 
only.  This  gave  fifteen  degrees  of  freedom  for  the  treat¬ 
ments  sum  of  squares  and  sixteen  degrees  of  freedom  for  the 
error  sum  of  squares  (see  Table  XI t  ANOVA) . 


Table  XI 


ANOVA 

ii  i 

SOURCE 

D.F 

S.S. 

M.S. 

TREATMENTS 

15 

4121.09 

274.74 

ERROR 

16 

7146.88 

446.68 

total _ 

-31 

_ 1 1267.97 

TABLE  XII 


1 _ COMPARISON  VALUES _ 

. .  ■" 

STANDARD  ERROR 

7.47 

T  VALUE  AT  . 10 

a 

1.75 

T  VALUE  AT  .05 

a 

2. 12 

T  VALUE  AT  .01 

a 

2.92 

COMPARISON  VALUE  AT 

.  10 

a 

13.05 

COMPARISON  VALUE  AT 

.05 

m 

15.84 

COMPARS I ON  VALUE  AT 

■ill- 

» 

-2U93 

The  error  mean  square  of  446.68  was  used  to  compute  the 
standard  error  of  7.47.  This  standard  error  was  multiplied 
by  the  critical  values  of  t  (for  16  degrees  of  freedom)  at 

40 


the  alpha  *  .01,  .09,  and  .10  levels  of  significance  (shown 
in  Table  XII),  and  resulted  in  comparison  values  of  13.05  at 
alpha  ■  .10,  15.84  at  alpha  »  .05,  and  23.83  at  alpha  =  .01. 

Significance  of  Resul ts 

The  effect  means  for  treatments  (TABLE  IX)  were  con¬ 
trasted  with  the  comparison  values  (TABLE  XII)  to  determine 
the  significance  of  the  effects  of  each  treatment.  If  the 
effect  mean  exceeded  a  given  comparison  value  the  main 
effect  (or  interaction  effect)  for  that  treatment  is  statis¬ 
tically  significant  at  the  corresponding  alpha  level.  Main 
effect  B,  transportation  time,  was  significant  at  the  alpha 
»  .01  level.  Main  effect  0,  maintenance  duration,  as  well 
as  the  BO  interaction,  were  significant  at  the  alpha  *  .10 


IV.  Summary,  Conclusions,  and  Rec ommen da t i on s 

The  six  objectives  this  research  was  to  meet  were: 

1.  To  conduct  a  thorough  review  of  the  ALCM  spare  engine 
system  to  determine  the  system's  relevant  variables  and 
their  interrelationships,  and  the  amount  and  type  o-f  varia¬ 
bility  in  these  relationships. 

2.  To  build  a  computer  simulation  model  o-f  the  system  that 
would  re-flect  the  -findings  o-f  this  review. 

3.  To  experiment  with  the  model  and  assess  the  significance 
of  changes  in  the  variables  on  the  system's  operational 
capability. 

4.  To  document  the  derivation,  use,  applicability,  and  sig¬ 
nificance  of  the  model's  output. 

9.  To  incorporate  flexibility  in  the  model's  design  to 
allow  for  changes  that  will  occur  in  the  system's  future. 

6.  To  answer  three  research  questions: 

a.  Do  any  of  the  selected  variables  have  a  significant 
effect  on  the  ALCM  engine  operational  capability  when 
allowed  to  vary  within  their  probable  range  of  values  ? 

b.  Which  of  these  variables  are  significant  ? 

c.  What  are  the  implications  of  these  findings  ? 

This  chapter  will  summarize  the  effort  of  the  authors 
to  meet  these  objectives,  and  will  offer  recommendations  for 
further  study  in  this  area. 


Summary 


The  logistics  issue  addressed  in  the  research  is  the 
management  of  spares  acquisition  and  logistics  support  ac- 
tivites  -for  the  Air  Launched  Cruise  Missile  engine.  Effec¬ 
tive  management  of  a  complex  weapon  system  such  as  the  ALCM 
requires  careful  consideration  of  the  overall  logistics 
support  given  to  the  system.  This  consideration  includes 
the  number  of  repairable  spare  parts  to  purchase,  the  timing 
and  frequency  of  maintenance  for  these  parts,  and  the  effect 
of  both  of  these  aspects  on  the  operational  capability  of 
the  weapon  system,  throughout  its  useful  life.  This  re¬ 
search  focuses  on  an  alternative  method,  from  those  cur¬ 
rently  employed  by  the  Air  Force,  for  analyzing  the  spare 
engine  procurement  and  support  requirements  of  the  ALCM. 

Objective  1 .  The  ALCM  system  was  thoroughly  reviewed 
by  the  authors  to  determine  the  environment  and  characteris¬ 
tics  of  the  system.  Support  for  this  review  was  provided  by 
Engine  Logistics  Office  of  the  Aeronautical  Systems  Division 
at  Hright-Patterson  AFB,  Ohio.  A  conceptual  model  of  the 
system  was  developed  from  the  information  obtained  from  this 
office.  The  model  was  revised  and  corrected,  then  reviewed 
by  the  Engine  Logistics  Office,  which  confirmed  that  the 
model  was  an  accurate  representation  of  the  real-world  ALCM 
system. 

Objective  2.  A  computer  model  was  then  written  in  the 
SIMSCRIPT  II. 9  language.  This  model  was  designed  as  a  tool 


that  ALCM  system  managers  could  use  to  understand  the  ALCM 
system  and  to  determine  the  impact  that  changes  in  selected 
variables  might  have  on  the  system's  performance. 

The  authors  selected  five  variables  that  appeared  to 
have  the  potential  for  significant  impact  on  the  ALCM 
system.  The  possible  range  of  values  for  these  variables 
was  then  determined  by  reviewing  the  available  information 
on  the  system. 

Objective  3.  An  experimental  design  was  then  selected 
that  would  determine  the  actual  significance  of  changes  in 
these  variables  on  the  model's  dependent  variable.  The 
factorial  design  chosen  allowed  the  determination  of  the 
impact  of  both  the  caain  and  interaction  effects  with  a 
single  analysis.  The  experiment  was  conducted  on  the  CDC 
CYBER  computer  and  analyzed  using  the  Yates'  method  for 
ANOUA.  It  was  found  that  the  transportation  time  was  sta¬ 
tistically  significant  at  the  alpha  *  .01  level,  and  the 
maintenance  duration  and  the  transportation/maintenance 
interaction  was  significant  at  the  alpha  *  . 10  level. 

Obj ective  4.  Appendices  A  through  6  document  the  com¬ 
puter  model's  operation,  verification,  input  requirements, 
and  output.  Appendix  A  illustrates  some  of  the  capabilities 
of  the  model  to  provide  estimates  of  future  states  of  the 
ALCM  system  that  managers  may  find  valuable  for  long  range 
system  planning.  Appendix  B  explains  some  of  the  terms 
peculiar  to  the  SIMSCRIPT  language  that  are  used  in  the 
model.  Appendix  C  explains,  in  detail,  the  line  by  line 


operation  and  design  logic  o-f  the  model.  This  appendix  will 
give  other  modelers  the  depth  of  understanding  necessary  to 
adapt  and  modify  the  model  for  their  particular  use. 
Appendix  0  gives  examples  of  the  input  files  required  to  run 
the  model  and  specifies  the  values  of  those  factors  consi¬ 
dered  as  constants  in  this  research.  Appendix  E  is  the 
numbered  program  listing  referenced  in  the  other  appendi¬ 
ces.  Appendix  F  is  an  explanation  of  the  terms  and  vari¬ 
ables  used  in  the  model.  Appendix  6  is  an  example  of  the 
procedure  used  to  verify  the  correct  operation  of  the  model. 

Objective  5.  The  computer  model  was  designed  with  the 
flexibility  to  easily  modify  all  the  assumptions  and  limita¬ 
tions  built  into  it,  so  that  newly  discovered  relevant  vari¬ 
ables  and  different  levels  of  factors  could  be  incorporated 
as  the  system  evolves.  In  most  cases  this  can  be  accom¬ 
plished  by  modifying  a  short  input  file  found  in  Appendix  D. 
The  documentation  found  in  the  other  appendices  will  give 
an  experienced  modeler  the  flexibility  to  explore  numerous 
alternative  courses  of  action  in  experimenting  with  this 
model  . 


Objective  6a.  The  analysis  of  the  experimental  results, 
presented  in  Chapter  3,  clearly  shows  that  some  of  the 
selected  variables  do  have  a  significant  impact  on  the 


system's  operational  capability,  as  defined  by  the  authors. 
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Objective  6b.  Transportation  time,  maintenance  dura¬ 
tion,  and  their  interaction  proved  significant  at  the  alpha 
*  . 10  level.  This  conclusion  is  based  on  the  mean  effects 
and  comparison  values  depicted  in  Tables  IX  and  XII  of 
Chapter  3.  All  the  other  variables  in  the  study  were  not 
significant  below  the  alpha  »  .40  level. 

Recommendations 

Objective  6c.  The  first  recommendation  presented  is 
also  the  most  important.  It  is  the  necessity  for  full 
validation  of  the  model.  Without  this  validation,  the  sig¬ 
nificant  effects  shown  for  transportation  time  and  mainte¬ 
nance  duration  should  not  be  acted  on  by  ALCM  system  mana¬ 
gers.  Validation  is  necessary  to  confirm  the  assumptions 
inherent  in  the  models  underlying  structure  and  constant 
parameter  values  before  the  results  of  this  research  can  be 
accepted  as  accurate. 

This  validation  should  include  an  investigation  of  the 
assumptions  made  in  the  model .  First,  depot  2  (OCALC) 
appears  to  be  under-utilized  in  its  first  four  years  of 
operation  because  of  the  policy  that  limits  depot  2  to 
performing  only  limited  overhauls  <28> .  Second,  the  assump¬ 
tion,  made  by  the  authors,  that  selection  of  a  spare  engine 
from  a  particular  depot  is  made  on  the  basis  of  the  depot 
with  the  most  spare  engines  available,  may  be  invalid.  A 


policy  of  selecting  the  oldest  engine  from  either  depot's 


stocks  may  be  mors  appropriate.  Third,  the  depot  selected 
to  service  a  particular  engine  requiring  a  limited  overhaul 
was  based  on  using  the  depot  with  the  lowest  utilization 
rate,  whereas  a  regional  servicing  policy  may  be  more  appro¬ 
priate.  Fourth,  the  author's  use  o-f  the  model 's  engine 
conversion  routine  is  based  on  an  attempt  to  convert  as  many 
engines  as  possible  during  their  longer  servicing  period. 
The  emphasis  here  is  on  conserving  maintenance  resources  by 
performing  extensive  maintenance  <the  conversion)  only  on  an 
engine  that  would  normally  be  scheduled  for  extended  mainte¬ 
nance  <ful 1  ,  repair,  and  refurbishment  services).  Other 
considerations  may  be  more  important  than  this  emphasis  in 
determining  the  conversion  schedule. 

The  next  recommendation  is  an  in-depth  study  of  the 
utility  of  the  dependent  variable,  as  expressed  in  the 
model ,  as  an  indicator  of  the  ALCM  engine's  operational 
capability.  The  actual  correlation  between  the  amount  of 
time  an  engine  spends  as  an  operational  asset  beyond  its 
warranted  life,  and  its  probability  of  successfully  firing 
and  operating  when  a  demand  is  placed  on  it,  has  not  yet 
been  established.  Further  analysis  of  the  results  of  the 
current  test  program,  and  an  extension  of  this  program  to 
include  engines  operational  past  their  warranted  life,  may 
be  required  to  establish  this  correlation.  Once  this  corre¬ 
lation  has  been  established,  a  new  experiment  should  be 
performed  to  test  for  a  significant  change  in  system  cap¬ 
ability  due  to  changes  in  the  transportation  time  and  main- 


tenance  duration  parameters.  Evan  though  these  par ama tars, 
as  used,  currantly  indicata  a  significant  effect  on  tha 
dapandant  variabla,  tha  dapandant  variable's  actual  corral a- 
tion  with  system  capability  (possibly  at  lass  than  a  ona  to 
ona  ratio)  may  not  indicata  a  significant  changa  in  this 
capabi 1 i ty. 

Finally,  tha  assumption  of  a  uniform  distribution  for 
aach  of  tha  stochastic  procassas  in  tha  modal  is  basad  on 
inadaquata  information  concarning  tha  actual  probability 
distributions  that  should  apply  in  aach  case.  Thasa  distri¬ 
butions  should  ba  datarminad  from  an  analysis  of  anginaaring 
data  and  tast  rasults,  and  tha  modal  updatad  to  raflact  tha 
corract  distributions. 

Onca  tha  varification  is  complata  and  tha  assumptions, 
as  'prasantad,  ara  varifiad,  an  in-dapth  study  of  transporta¬ 
tion  tima  and  maintananca  duration  should  ba  conductad  to 
ravaal  tha  actual  distribution  of  valuas  thasa  variables  ara 
likely  to  assume.  Tha  authors  recommend  incorporating  ac¬ 
curate  probability  distribution  functions  for  aach  of  these 
significant  variables  into  tha  present  modal ,  than  experi¬ 
menting  with  tha  modal  to  produce  accurate  predictions  of 
the  dapandant  variabla  and  tha  other  output  variables  men¬ 
tioned  in  Appendix  A. 

Furthermore,  onca  tha  modal  is  validated  and  accurate 
probability  distribution  functions  for  tha  significant  vari¬ 
ables  ara  incorporated,  tha  modal  may  ba  used  to  tast  the 
effects  of  changes  in  management  policy.  For  example,  tha 


model  has  an  untested  capability  to  vary  the  engine  servic¬ 
ing  capacity  of  each  depot  at  any  time.  This  capability,  in 
conjunction  with  the  (untested)  capability  to  allow  the 
early  (before  the  due  date)  overhaul  of  an  engine,  may 
significantly  affect  the  operation  of  the  model .  Management 
may  adopt  a  policy  of  early  overhauls  to  smooth  out  the 
"peaks  and  valleys"  in  service  requirements,  and  to  insure 
that  these  "peaks"  do  not  exceed  a  1 ess-than-unl imi ted  ser¬ 
vice  capacity  at  a  depot.  The  model  will  be  able  to  show 
management  the  implications  of  this  change  in  pol  icy. 

A  final  recommendation  is  to  examine  the  possibility  of 
adapting  the  ALCM  model  to  reflect  the  operational  environ¬ 
ment  of  the  Ground  Launched  Cruise  Missile  (6LCM)  or  the 
Submarine  Launched  Cruise  Missile  (SLCM) ,  both  of  which  use 
the  same  type  of  engine  as  the  ALCM.  These  systems  are 
further  behind  the  ALCM  in  development,  and  final  decisions 
on  the  number  of  spare  engines  to  procure  have  not  been 
made.  A  slightly  modified  model  could  be  used  to  determine 
the  effects  on  the  system  of  different  numbers  of  spare 
engines.  An  evaluation  of  these  effects  could  help  managers 
determine  the  appropriate  number  of  spares  to  procure. 


Appendix  A:  Simulation  Output  Summary 

This  appendix  illustrates  some  of  the  capabilities  of 
the  model  to  provide  estimates  of  future  states  of  the  ALCM 
system  that  managers  may  find  valuable  for  long  range  system 
planning.  It  is  divided  into  three  parts,  the  first  giving 
a  "snapshot*  of  the  state  of  the  system  at  0000  hours  on  the 
f irst  day  of  each  month  (pages  94-60) .  The  second  part 
summarizes  the  activities  that  have  occurred  for  each  month 
of  the  simulation  run  (pages  61-67) .  The  third  part  reviews 
the  system's  operation  over  its  entire  simulated  life,  re¬ 
cords  the  total  number  of  broken  and  overdue  missiles,  and 
their  average  time  on  base  past  their  failure  or  overdue 
dates  (page  67).  This  last  item  is  the  dependent  variable 
examined  in  this  research  effort. 

The  following  is  an  explanation  of  the  codes  used  in 
part  1  of  the  output  summary  (the  numbers  (1-123  down  the 
left  column,  under  each  year,  indicate  the  month  for  each 
row  of  output) : 

NQ1  and  NQ2  -  the  number  of  engines  waiting  for  servicing  at 
each  depot  because  of  a  shortage  in  the  depot's  service 
capability  (depot  1  refers  to  Williams  and  depot  2  refers  to 
OCALC)  . 

NX  1  and  NX2  -  the  number  of  engines  being  serviced  by  each 


depot . 


NR  1  and  NR2  -  the  number  of  repaired,  serviceable  engines  in 
each  depot's  stocks. 
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NTS  -  the  number  of  engines  currently  being  tested. 
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NAS  -  the  total  number  of  operational  engines  deployed  to 
bases  in  the  system. 

NSS  -  the  number  of  spare  engines  required  by  the  system  to 
replace  all  broken  and  overdue  engines,  provide  for  spare 
test  engines,  and  fill  the  transportation  and  maintenance 
pipeline.  This  number  does  not  count  engines  in  depot 
repaired  stocks  if  there  is  no  demand  for  them. 

NKS  -  the  number  of  engines  that  require  a  spare  engine,  due 
to  failure  or  being  overdue  for  scheduled  maintenance,  but 
cannot  obtain  one  due  to  lack  of  their  availability.  This 
number  indicates  the  excess  of  demand  over  supply  for  spare 
engines. 

N6N  -  the  number  of  failed  engines  awaiting  a  replacement 
spare  engine.  A  broken  engine  will  stay  on  base  a  minimum 
of  TRANSPORT . DAYS  before  being  replaced  due  to  the  demand- 
pull  supply  concept  used  in  the  system. 

NOV  -  the  number  of  engines  in  a  deployed  status  that  have 
exceeded  their  warranted  lifetimes  since  their  last  over¬ 
haul  .  Due  to  the  structure  of  the  model ,  these  engine  are 
counted  as  being  on  base  a  minimum  of  TRANSPORT . DAYS  before 
being  replaced.  However,  the  spare  engine  reorder  process 
is  actually  initiated  TRANSPORT . DAYS  prior  to  the  engine's 
actual  overdue  date.  An  adjustment  is  made  in  the  model's 
output  to  correct  these  excess  overdue  days. 


A  knowledge  of  the  most  probable  state  of  these  vari¬ 
ables  can  be  extremely  valuable  to  system  managers  in  deter¬ 
mining  depot  maintenance  requirements  over  the  years  ahead. 
The  NAS  counter  can  give  a  clear  picture  of  operational 
missile  strength  as  it  might  change  over  the  system's  life. 
Combined  with  the  information  available  from  the  main  output 
variable,  the  average  time  a  missile  exceeds  it  warranted 
life  while  deployed,  system  managers  should  be  able  to 
determine  probable  readiness  levels  for  the  ALCM  system 
throughout  its  useful  life. 

Trends  shown  in  the  "snapshot*  pictures  (part  1)  of  the 
system's  variables  can  give  managers  a  great  deal  of  useful 
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information.  For  instance,  in  the  output  example  shown  in 
this  appendix,  the  system  seems  capable  of  handling  the 
demand  for  spare  engine  for  all  years  except  1987  to  1992. 
The  demand  quickly  exceeds  the  supply  and  stays  that  way  for 
five  years,  with  demand  peaking  at  407  engines  and  only  119 
spare  engines  available.  This  trend  should  indicate  that 
further  research  into  the  cause  of  this  apparent  "bottle¬ 
neck"  may  be  worthwhile  so  that  solutions  can  be  developed 
in  time  to  prevent  the  problem  from  occurring.  This  may 
require  the  use  of  premium  transportation  for  spare  engines, 
or  expediting  depot  operations.  The  model  can  indicate 
where  and  when  problem  areas  may  occur  and  what  their  most 
likely  causes  are  so  that  action  can  be  taken  early  enough 
to  prevent  these  problems. 

Part  2  of  the  output  summary  gives  additional  informa¬ 
tion  that  will  interest  system  managers,  especially  depot 
managers.  It  gives  monthly  information  on  the  following 
variabl es: 

INCR  -  the  increase  in  the  number  of  spare  engines  required 
over  the  previous  month. 

TREQ  -  the  maximum  number  of  engines  required  at  any  time 
during  the  month. 

A 101, A 104  -  the  average  age  <  in  days  past  the  engine's 
last  overhaul  date)  for  each  type  (101  or  104)  of  engine. 
These  counters  apply  only  to  deployed  engines.  This  may 
serve  as  another  indicator  of  the  readiness  of  the  ALCM 
fleet. 

MINR  -  the  number  of  limited  overhauls  performed  by  the 
depots  during  the  month. 


MAJR  -  the  number  of  full  overhauls  performed  by  the  depots 
during  the  month. 

UNSC  -  the  number  of  unscheduled  overhauls  (due  to  failure) 
performed  by  the  depots  during  the  month. 

REFB  -  the  number  of  test  ref urbishments  performed  by  the 
depots  during  the  month. 

CONV  -  the  number  of  101  to  104  conversions  performed  by  the 
depots  during  the  month. 

Part  3  of  the  output  summary  shows  the  total  number  of 
engines  that  have  failed  or  exceeded  their  warranted  life 
before  being  serviced.  Since  there  are  only  1830  engines 
manufactured  and  failures  or  over dues  may  exceed  7000,  these 
figures  reflect  the  many  "lifetimes"  of  each  engine  over  the 
life  of  the  simulation.  An  individual  engine  may  have 
failed  early  for  three  out  of  the  five  times  it  was  deployed 
or  redeployed  to  an  operational  base.  This  will  be  re¬ 
flected  as  three  failed  engines  in  the  system's  counter. 

Because  of  the  model's  structure,  all  engines  that  are 
exchanged  at  or  past  their  warranted  life  are  counted  as 
overdue  (those  that  meet  or  exceed  their  warranted  life). 
The  total  number  overdue  will  thus  reflect  the  total  number 
of  engines  deployed  that  do  not  fail  and  are  not  used  for 
tests.  The  "average  number  of  days  overdue"  thus  reflects 
the  fleet-wide  average  days  overdue  for  those  engines  that 
have  met  or  exceeded  their  warranted  life. 
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PART 


THE  MAXIMUM  NUMBER  OF  SPARE  ENGINES  REQUIRED  OVER  THE 
LIFE  OF  THE  SYSTEM  IS  467 
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PART  2 


0  MISSILES  WERE  BROKEN  AT  DEPLOYMENT  BASES  THROUGHOUT  THE 
LIFE  OF  THE  SYSTEM.  THEY  AVERAGED  0.  DAYS  ON  BASE  (BRO¬ 
KEN)  BEFORE  BEING  REPLACED  FOR  A  TOTAL  OF  8.  DAYS  IN 
INOPERABLE  STATUS. 


6936  MISSILES  WERE  KEPT  IN  A  DEPLOYED  STATUS,  UP  TO  OR  PAST 
THEIR  WARRANTED  LIFE,  THROUGHOUT  THE  LIFE  OF  THE  SYSTEM. 
THEY  AVERAGED  36.62  DAYS  ON  BASE  (OVERDUE)  BEFORE  BEING 
REPLACED  FOR  A  TOTAL  OF  233999.80  DAYS  OVERDUE. 


Appendix  Bi  G1  ossary  o-f  Sel ected  SIMSCRIPT  Term* 


Refer  to  APPENDIX  Es  Program  Listing  -for  the  context  in 
which  the  -following  terms  are  used.  Words  appearing  in  all 
CAPITALS  are  terms  used  in  the  program. 


ATTRIBUTES:  ATTRIBUTES  are  the  "memory  cells  <19s3>*  o-f 
ENTITIES  and  PROCESSES.  They  de-fine  the  characteristics  of 
each  ENTITY  or  PROCESS.  Attributes  may  be  set  to  different 
values  or  examined  by  the  actions  of  the  program. 

ENTITIES!  ENTITIES  are  the  model's  objects.  They  represent 
the  devices  or  objects  that  exist  in  the  real  systam.  Like 
a  subscripted  variable,  each  ENTITY  can  represent  many 
values  at  the  same  time,  by  the  carrying  of  ATTRIBUTES 

< 18 i 222) . 

FOR  EACH  ...  OF  (SET) s  This  phrase  causes  a  group  of  state¬ 
ments  to  be  executed  for  each  object  stored  in  the  specified 
SET.  It  can  be  modified  with  WHILE,  UNTIL,  WITH  OR  UNLESS 
phrases  so  that  the  statements  are  only  executed  for  certain 
of  the  objects,  or  UNTIL  a  specific  object  is  encountered 
< 19s 191) . 

PROCESSES!  PROCESSES  are  the  sequence  of  actions  that  an 
object  undergoes  as  it  passes  through  the  model.  There  may 
be  many  copies  of  each  PROCESS  in  existence  at  any  one  time, 
each  processing  a  different  object.  "The  process  routine 
may  test  for  system  conditions  and  take  alternative  courses 
of  action  < 19 ! 2-3) a . 

RESOURCES!  RESOURCES  are  auseda  by  the  model's  objects.  If 
the  number  of  units  of  the  RESOURCE  requested  by  an  object 
are  available,  the  units  are  taken  and  held  by  the  object 
until  it  releases  them.  If  the  RESOURCES  are  not  available, 
the  requesting  object  is  placed  in  a  queue  to  wait  for  the 
units  to  became  available  <19:2-4). 

ROUTINES:  ROUTINES  are  similar  to  subroutines  in  that 
values  may  be  passed  to  them,  the  ROUTINE  may  perform  some 
operation,  and  values  may  be  returned  by  them  to  the  CALLing 
ROUTINE  or  PROCESS. 

SCHEDULE/ ACT I VATE :  SCHEDULE  and  ACTIVATE  both  'activate  the 
future  occurrence  of  a  process  < 19:99) a  by  assigning  a 
future  time  <the  AT,  IN  or  NOW  phrase)  for  the  PROCESS  to 
start.  At  that  moment  in  (SYSTEM)  time,  the  previously 
scheduled  PROCESS  begins  to  occur  and  effect  the  system. 
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PROCESS**  may  be  suspended  for  a  certain  amount  of  time 
after  they  are  started  by  using  the  WAIT  or  WORK  statements. 

SETSi  SETS  are  ordered  groups  of  objects  that  exist  in  the 
model.  ENTITIES  "can  either  own  or  belong  to  a  set 
< 13*3-35). ■  ATTRIBUTES  that  order  the  SET  are  automatically 
created  by  the  SYSTEM.  These  "owner"  ATTRIBUTES  describe 
the  number  of  objects  currently  in  the  SET,  and  the  first 
and  last  member  of  the  SET.  Member  ATTRIBUTES  describe  the 
predecessor  and  successor  objects  of  each  SET  member,  and 
identify  if  the  object  is  currently  a  member  of  that  SET. 
Objects  can  be  placed  in  or  removed  from  SETS  by  the  actions 
of  the  program  (FILE  and  REMOVE  phrases) ,  and  the  order  of 
that  placement  can  also  be  changed  by  program  actions(  15*3- 
35-38) . 

SYSTEM:  The  SYSTEM  is  a  term  used  for  the  operating  systam. 
It  is  in  existence  to  act  as  the  QkNing  agency  for  various 
SETS  that  are  not  G!«N*d  by  other  ENTITIES.  It  may  also  have 
its  own  ATTRIBUTES  <19:281-286). 


TALLY/ACCUMULATE:  The  TALLY  statement  is  used  to  collect 

various  types  of  statistics  on  system  VARIABLES  These 
statistics  include  the  SUM,  NUMBER,  MEAN,  VARIANCE  and  many 
other  values.  The  ACCUMULATE  statement  calculates  similar 
statistics,  but  weights  the  resultant  value  with  the  amount 
of  time  the  variable  remains  in  any  given  state.  Thus  the 
TALLY  of  2  for  1  minute,  and  6  for  2  minutes  would  be  4, 
while  the  ACCUMULATE  for  these  values  would  be  5. 

VARIABLES: 

GLOBAL:  Global  VARIABLES  are  names  of  memory  locations 
that  are  known  (can  be  examined  and/or  changed)  throughout 
the  entire  program.  VARIABLES  are  made  global  by  declaring 
them  in  the  PREAMBLE  section  (19:44). 

LOCAL:  (Recursive)  local  VARIABLES  are  names  of  memory 

locations  that  are  known  only  within  the  particular  copy  of 
the  PROCESS  they  appear  in.  (Saved)  local  VARIABLES  are 
known  throughout  every  copy  of  the  particular  PROCESS  they 
are  used  in.  Local  VARIABLES  are  declared  in  the  PROCESS 
itself,  and  override  the  global  VARIABLE  of  the  same  name. 


Appendix  Cs  Model  Operation  and  Decision  Logic 

This  appendix  explains  the  operation  and  decision  logic 
o-f  the  SIMSCRIPT  model  listed  in  Appendix  Es  Program 
Listing. 

The  purpose  of  this  appendix  is  to  explain  the  computer 
model  to  those  users  Mho  desire  a  detailed  understanding  of 
the  model's  operation  and  decision  logic.  This  depth  of 
understanding  is  necessary  if  the  user  desires  to  modify  the 
model  to  reflect  changing  parameters  or  system  structure ,  to 
gather  information  on  aspects  of  the  system  not  explicitly 
addressed  in  this  model,  or  to  experiment  Mith  those  factors 
of  the  model  in  being,  but  not  the  subject  of  this  research. 

Those  statements  in  the  model  Mhich  are  sel f-expl ana- 
tory  as  to  their  underlying  assumptions,  their  purpose  and 
their  operation  are  not  addressed  in  this  appendix.  To  help 
guide  the  user  through  the  sequential  f 1 ow  of  the  model, 
Figure  2:  Process  FI ow  Chart  should  be  examined.  This 
figure  depicts  the  possible  "paths”  through  the  model.  It 
shows  al 1  the  processes  that  may  activate  a  given  process 
and  al 1  the  processes  that  may  be  activated  bv  that  same 
process.  In  addition,  the  interested  user  should  refer  to 
Appendix  B:  Glossary  of  SIMSCRIPT  Terms  for  an  explanation 

of  some  of  the  terms  peculiar  to  SIMSCRIPT,  and  to 
Appendix  F:  Explanation  of  Program  Terms,  for  a  description 
of  the  variable  names,  sets,  entities  and  other  items  used 
in  the  program.  For  a  more  detailed  explanation  of  the 
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SIMSCRIPT  language,  refer  to  the  three  texts  by  C.A.C.I. 
(references  15,  18  and  1?) . 

The  line  numbers  cited  on  the  left  hand  side  of  this 
appendix  refer  to  those  in  Appendix  E.  The  topic  headings 
refer  to  the  main  sections  and  processes  of  the  program  in 
Appendix  E. 


PREAMBLE 


94  See  routine  DATE  line  469. 

95  See  process  IN.ACTIGN  lines  629-630 

(144-155)  These  statements  set  up  the  system  routines  needed 
to  automatically  gather  statistics  on  the  number 
of  spare,  broken,  and  overdue  engines. 

144-147  MAX .  PER  .MONTH  is  the  maximum  number  of  spares 
needed  during  a  one-month  period,  after  which  it 
is  reset  to  zero  and  recalculated  for  the  next 
month  (  see  MONTHLY. STATIST ICS) .  LIFE. MAX  is  the 
maximum  number  of  spares  needed  over  the  1  if e  of 
the  system,  (see  note  1  and  TALLY/ACCUMULATE  in 
Appendix  B) 

148-151  BROKENUM  is  the  number  of  engines  broken  over  the 
life  of  the  system.  BROKESUM  is  the  summation  of 
the  time  all  engines  spend  on  base  while  broken, 
(see  TALLY/ACCUMULATE  in  Appendix  B) 

148-151  OVERNUM  is  the  number  of  engines  overdue  over  the 
life  of  the  system.  OVERSUM  is  the  summation  of 
the  time  all  engines  spend  on  base  while  overdue 
(see  TALLY/ACCUMULATE  in  Appendix  B) 

MAIN 


166  SIMU7  is  the  file  containing  the  variable  input 

parameters.  SIMU8  is  the  file  to  which  all 
program  output  is  written. 
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192-193 


216-217 


218-219 


221-222 


231,235 


,  *V«T-  *V*V  ^ 


The  maximum  number  of  anginas  that  can  ba  serviced 
at  any  ona  tima  by  aach  DEPOT  is  sat  at  this 
point.  This  capacity  can  ba  changad  at  a  latar 
data  by  tha  DEPOT < 1/2) .CAPACITY. SCHEDULE  procass. 
Tha  original  capacity  of  280  units  is  aquivalant 
to  an  “unlimited”  sarvica  capacity,  sinca  tha 
maximum  numbar  o-f  anginas  tha  dapot  would  ba 
raquirad  to  sarvica  at  any  ona  tima  is  115  sparas 
and  4  to  5  OTL  tast  anginas. 


This  months  < COUNT  -  month)  MAINTENANCE. RECORD  is 
updatad  by  tallying  tha  typa  o-f  maintananca  to  ba 
par-formad  < INDEX)  on  tha  incoming  angina.  INDEX 
is  obtained  -from  tha  TYPE. SERVICE  attribute  o-f  tha 
angina. 

After  this  point,  tha  typa  of  sarvica  indicator 
< INDEX)  is  sat  to  indicate  LIMITED  < 1)  or  FULL 
(2)  for  use  in  controlling  which  anginas  are 
converted.  Sinca  all  types  of  maintananca  except 
limited  are  of  tha  longer  duration,  they  are 
treated  as  fulls. 

These  statements  insure  only  tha  F 107- 101  typa 
angina  is  converted,  tha  currant  simulation  tima 
(TIME.V)  is  past  tha  start-conversion  data,  and 
tha  conversion  quota  for  that  angina  typa 
(MAY . CONVERT)  has  not  bean  exhausted.  Tha  conver¬ 
sion  period  is  opan-andad  on  tha  back  side  to 
insure  all  anginas  will  eventually  ba  converted, 
since  soma  of  them  may  ba  out  of  cycle  during  tha 
scheduled  conversion  period. 

All  conversion  are  completed  at  DEPOT 1  only. 

Tha  tima  raquirad  to  REPAIR  and  angina  is  equal  to 
tha  tima  raquirad  for  a  FULL  overhaul . 

After  an  overhaul  of  ona  typa  (REPAIR/FULL,  or 
LIMITED),  tha  next  overhaul  will  ba  of  tha  oppo¬ 
site  typa  (LIMITED  or  FULL). 

Maintananca  performed  on  anginas  that  are  con¬ 
verted  is  double-counted.  Both  tha  scheduled 
maintananca  (FULL,  LIMITED,  REFURB,  or  REPAIR)  and 
tha  actual  maintananca  (CONVERSION)  is  recorded. 


241,244  Both  CONVERSION*  and  REFURBi shmen ts  require  a  sub¬ 
sequent  LIMITED  overhaul . 

249  The  angina" »  at tri but as  indicating  whan 
maintananca  was  performed  and  whan  it  will  ba  dua 
again  ara  updatad  in  routina  DATE. 

250  If  tha  angina  has  baan  countad  as  a  raquirad 

spare,  this  statamant  ramovas  : t  from  tha  sparas 
raquirad  countar  and  updatas  its  attributas  to 
reflect  that  it  is  no  longar  a  raquirad  spara. 
<saa  nota  1> 

251-257  If  tha  angina  cama  from  tha  PRODUCT  I  ON.  POOL,  it 

had  fail  ad  or  bacama  ovardua  bafora  its  assambly 
with  an  airframa  and  bafora  baing  shippad  to  a 
basa.  Thasa  statamant*  raturn  it  to  tha  PRODUC¬ 
TION. POOL  to  eventually  by  shippad  out  to  a  basa. 

259-243  If  tha  angina  cama  from  an  OTL  missile,  it  must  ba 
raplacad  in  that  missila  and  raturnad  to  its 
originating  basa.  It  is  not  a  spara  angina 
avai labia  for  ganaral  usa.  (saa  nota  2) 

267-277  If  tha  rapairad  angina  is  tha  only  avai labia 

spara,  indicatad  by  both  DEPOT'S  rapairad  stocks 
<N. REPAIRED. SET)  baing  ampty  <0> ,  and  a  daman d 
alraady  axists  for  a  spara  angina  (there  is  an 
angina  in  tha  TAKE. SET  or  EARLY . OVERHAUL*  ara 
authorized) ,  tha  angina  is  immadiataly  sant  to  ba 
usad  as  a  spare  < IN. ACTION  is  activated  with  a 
specific  MSL) .  Otherwise,  tha  angina  is  placed  in 
tha  appropriate  rapairad  stock  (REPAIRED. SET)  and 
tha  system  is  notified  of  its  availability 
(IN.ACTION  is  activated  without  a  specific  MSL)  . 


284-284  This  process  is  active  for  a  two-year  period  <1982 
and  1983),  twelve  months  a  year  < 1  to  12)  and  five 
times  par  month  (1  to  5) . 

288  If  tha  number  of  spara  anginas  to  ba  produced 

{NUMBER. SPARES)  has  bean  reached  <L)  ,  tha  process 
is  terminated. 

291  This  statement  simulated  the  random  nature  of  the 

spare  engine  production  schedule,  'creating*  the 
engine  within  pi us-or-minus  two  days  (uniformly 
distributed)  of  its  scheduled  production  date. 


These  statements  initialize  the  attributes  o-f  the 
newly  created  engine,  defining  its  character¬ 
istics. 

All  spare  engines  are  produced  at  the  Williams 
plant  (also  DEPOT  1)  . 

See  MAINTENANCE,  lines  267-277. 


320-32 6 


Reads  from  input  file  SIMU11. 

Reads  the  number  of  days  past  simulation  start-up 
to  schedule  a  test  (TEST. DAYS)  and  the  type  of 
test  to  be  scheduled  ( TEST. TYPE) .  Then  it 
schedules  the  process  TEST. PICK  to  select  a  test 
engine/missile.  This  is  repeated  for  the  number 
of  tests  to  be  performed  (NUMBER. TESTS) . 


332-333 


Selects  a  missile  (PICK)  from  the  set  of 
operational  missiles  (ALERT. MISSILE. SET)  for  test¬ 
ing.  The  missile  selected  is  the  oldest  one  that 
has  not  already  been  selected  for  testing 
(TEST. STATUS  *  NONE)  and  is  not  already  being 
processed  for  an  overhaul  or  repair  (CLAIM  not 
equal  to  TAKEN) . 

Assigns  the  type  of  test  the  engine  will  undergo 
to  TEST. STATUS. 


(333-343)  For  EVIP  tests  only. 

334-344  See  MAINTENANCE  lines  267-277,  but  substitute 
TAKE. SET  for  REPAIRED. SET.  (see  note  1) 

(346-360)  For  OTL  and  JTA  tests  only. 

346-347  Missiles  selected  for  testing  are  not  counted  as 

overdue  (they  are  not  part  of  an  operational 
force)  . 

330  OTL  and  JTA  missiles  are  automatically  removed 

from  the  ALERT. MISSILE. SET  since  the  do  not 
require  a  spare  engine. 
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354-356  OTL  missiles  are  shipped  to  the  tost  site  -for 

testing.  (set  not*  2) 

357-35?  JTA  missiles  are  considered  destroyed  at  this 

point  since  they  no  longer  add  to  or  subtract  -from 
the  variables  o-f  interest  in  the  simulation 
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378-382 

383 


Reads  -from  input  -file  SIMU13. 

If  no  missiles  are  to  be  shipped  that  month, 
to  process  the  next  month. 


skip 


Break  the  shipment  o-f  missiles 
<MSL. PRODUCTION. NUMBER)  into  four 
< NUMBER .TO . SEND) . 


for  the  month 
equal  shipments 


For  the  first  three  shipments  of  the  month  <  days 
7,14,  and  21,  plus  or  minus  2  days)  indicate  the 
NUMBER. TO. SEND  to  process  SHIP. MISSILE. 

Ship  the  remainder  of  missiles  for  the  month  on 
the  twenty-eighth  day  of  the  month. 


393 

396-398 

399-480 

405-406 


Ship  the  number  of  missile  received  from 


^nip  xne  numovr  o-r  missile 
MISSILE. PRODUCTION,  one  at  a  time. 

If  a  missile  is  available  from 
stockpile  < PRODUCT I ON. POOL) ,  select 


th< 
i  t . 


missi 1 e 


If  no  missiles  are  available,  wait  one  day  and  try 
it  again. 

If  the  current  base's  quota  of  missiles 
<BASE.MISSILE.RGMT)  has  not  been  filled  (equal  to 
BASE. MISS I LE. COUNT ER) ,  ship  a  missile  (activate  a 
DEPLOY)  to  that  base  and  increase  that  base's 
total  by  one.  (see  note  2) 


407-410 


If  the  currents 
begin  shipping  to 


base's  quota  has 
the  next  base. 


been  filled, 
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428 


Reads  -from  input  -file  SIMU19 


428  If  no  engines  are  to  be  produced  that  month,  skip 
to  the  next  month. 

429  Calculate  the  time  interval  < DATE. TO. HAKE. ENGINE) 
between  each  engine's  production  for  the  month. 

430-434  Schedule  a  CREATE. ENGINE  every  time  interval  until 
the  number  of  engines  to  be  produced  that  month 
has  been  reached. 


442-448  See  SPARE. ENGINE. GENERATION  lines  293-298. 

449-490  Original -product ion  engines  are  shipped  to  BOEING 
and  place  in  its  missile  PRODUCT I ON. POOL.  Since 
engine  production  is  so  far  ahead  of  missile 
production,  and  is  projected  to  stay  so,  no  time 
delay  is  required  for  this  shipment. 


QftlS 


497  The  current  simulation  time  <TIME.V>  is  recorded 
as  the  production/overhaul  date  of  the  engine  in 
the  attribute  START. DATE. 

498  If  a  randomly  selected  number  between  zero  and  one 
is  less  than  the  ENGINE. FA I LURE. RATE,  the  engine 
will  be  scheduled  to  fail  prematurely.  This 
process  simulates  the  probability  of  a  random 
engine  failure,  one  of  the  variable  factors  in  the 
model . 

499  The  length  of  time  an  engine  lives  before  a  fail¬ 
ure  is  assumed  to  be  uniformly  distributed  over 
the  normal  life  for  that  type  of  engine  <TERM> . 
The  failure  date  is  calculated  as  the  current  time 
<TIME.V)  plus  a  uniform  portion  of  its  normal  life 
I  RANDOM . F<  STREPM3)  X  TERM<TYPE< ENGINE) -108) I . 

441  Since  the  engine  will  fail,  its  next  service  type 

will  be  REPAIR. 


462 


The  process  FAILURE.  ACT  I  ON  is  activated  on  the 
date  the  engine  wilt  -fail.  This  is  the  "-flag" 
that  lets  the  system  know  an  engine  has  -failed. 
This  is  based  on  the  assumption  that  the  engine's 
-failure  is  detected  on  that  date.  Thus  the  model 
keys  on  the  failure  detection  date,  not  the  actual 
(unknown)  failure  date.  The  failure  rates  used  by 
the  model  are  actually  failure  detection  rates. 

464  If  the  random  number  selected  is  greater  than  or 

equal  to  the  FAILURE. RATE,  the  missile  will  last 
its  normal  life. 

466  For  an  engine  that  lasts  its  normal  life,  the 

process  OVERDUE. ACT I ON  is  activated  TRANSPORT .DAYS 
before  the  engine's  overdue  date.  This  parallels 
the  real -world  system,  where  a  spare  engine  would 
be  ordered  for  a  soon-to-be-overdue  engine  early 
enough  to  arrive  on  or  before  the  date  it  is 
needed. 

469  The  RANK. DATE  is  set  to  the  normal  life  of  both 

failure  and  overdue  engines.  Engines  are  then 
placed  in  the  ALERT. MISSILE. SET  oldest  RANK . DATE 
first.  This  sequences  all  missiles  for  test 

selection  from  the  ALERT. MISSILE. SET  based  on 
their  normal  lifetime.  Since  a  failure  is  not 
detected  until  it  happens,  test  selection  should 
not  be  biased  because  of  an  event  that  has  not  yet 
happened  (the  future  failure).  Test  selection  is 
based  on  using  the  engine  closest  to  its 
expiration  date  (the  oldest  engine  of  its  type  on 
base) .  If  engines  were  sequenced  according  to 
their  DATE. EXPIRES,  only  soon  to  fail  engines  (if 
any  were  on  base)  would  be  selected  for  testing, 
obviously  biasing  the  tests. 


SCHEIMLEji  fifflWEBSI  QM 

477  Reads  data  from  input  file  SIMU17. 

479-482  Schedules  a  COWERT  the  first  day  of  every  month 
from  January  1988  through  December  1991. 

CONVERT 

488  Reads  data  from  input  file  SIMU17. 


489-491  Reads  each  month'*  quota  for  conversion*  for  both 
types  of  service  (LIMITED  ■  LIMITED  quota}  FULL, 
REPAIR,  REFURBish  *  FULL  quota),  and  adds  these 
quotas  to  the  amount  remaining  from  last  month, 
(see  MAINTENANCE  lines  218-222) 


519  Places  the  engine  in  the  TEST.  SET  prior  to 

testing.  This  identifies  the  engine  as  being 
tested  if  it  fails  or  becomes  overdue  while  under¬ 
going  a  test. 

516-520  Simulates  testing  by  delaying  processing  for  the 
amount  of  time  required  for  the  test  (EVIP.TEST  or 
OTL.TEST  days) 

521  Checks  to  see  if  the  engine  is  still  in  the 

TEST. SET.  If  not,  the  engine  has  failed  during 
the  test  (FAILURE. ACTION  has  occurred) ,  and  the 
engine  has  been  previously  removed  from  testing. 
If  so,  the  process  is  terminated. 

522-526  If  this  is  an  OTL  missile  that  has  been  recovered 
after  testing  ( RANDOM. F( STREAM 1)  is  greater  than 
the  RECOVERY. FAILURE. RATE) ,  or  is  an  EVIP  test 
engine,  ship  the  engine/missile  to  the  depot  for 
service. 

527-529  Missile  is  an  OTL  that  was  not  recovered  and  is 
thus  destroyed. 


OVERDUE .ACTION 


535-537  If  the  DATE. EXPIRES  of  the  engine  being  processed 
is  not  equal  to  the  current  simulation  time 
(TIME.V),  this  OVERDUE. ACT I ON  is  the  originally 
scheduled  process  for  an  engine  that  has  been 
selected  for  testing,  and  refurbished  (thus 
receiving  a  new  DATE. EXPIRES)  before  its  original 
overdue  date.  These  statements  terminate  this 
■ghost*  OVERDUE. ACT I  ON. 

538-546  If  the  CLAIM  of  the  engine  is  TAKEN,  the  engine  is 
being  worked  on  by  another  process  (possibly 
TEST. PICK).  This  OVERDUE. ACT I ON  must  be  delayed 
until  the  previous  one  is  complete  (a  maximum  of 
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TRANSPORT. DAYS) .  This  precludes  having  two 
processes  trying  to  handle  an  engine  at  the  same 
time  (which  causes  the  system  to  make  a  "double" 
of  the  angina)  . 


(941-553)  For  thosa  anginas  in  tha  ALERT .MISSILE. SET  whan 
thay  become  ovardua: 

545-552  Saa  MAINTENANCE  Unas  267-277,  but  raplaca 
REPAIRED. SET  with  TAKE. SET. 


554-557  For  thosa  anginas  in  tha  dapot  stock  o-f  rapairad 
anginas  whan  thay  bacoma  ovarduai  ramova  tham  -from 
tha  rapairad  stock  and  initiata  servicing  at 
DEPOT!. 
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558-562  For  thosa  anginas  at  BOEING  whan  thay  bacoma 
ovarduai  ramova  tham  -from  tha  BOEING  stock  and 
initiata  servicing  at  DEP0T1. 

563-567  If  an  angina  is  INTRANSIT  (being  shipped  from  one 
place  to  another)  whan  it  becomes  ovardua:  it 
cannot  be  handled  by  tha  modal  until  it  arrives  at 
it  destination  (unknown  by  tha  modal).  Delay  this 
OVERDUE. ACT I ON  until  tha  angina  arrives  at  its 
destination  (its  arrival  time  is  a  maximum  of 
TRANSPORT. DAYS  away).  Than  reinitiate  this  pro¬ 
cess  from  tha  beginning. 


576-578  Saa  OVERDUE .ACTION  lines  535-537. 

529-581  See  OVERDUE. ACT I ON  lines  538-540. 

(582-595)  For  thosa  anginas  that  have  failed  while  in  tha 
ALERT. MISSILE. SET: 

586  As  opposed  to  ovardua  anginas,  failed  anginas 

cannot  be  used  as  operational  missiles  and  are 
thus  removed  from  tha  ALERT. MISSILE. SET. 


587-594 


596-600 


60  1-605 


Saa  OVERDUE. ACT I ON  lines  545-547  and  548-552. 
Saa  OVERDUE. ACT I ON  Unas  554-557. 

Saa  OVERDUE .ACT I ON  Unas  558-562. 

80 
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606-610  As  opposed  to  an  engine  that  becomes  overdue  while 
being  tested  (where  the  overdue  is  ignored) ,  an 
engine  -failure  occurring  in  a  test  must  be  removed 
-from  the  test  and  shipped  to  DEPOT  1  -for  servicing. 
This  assumes  that  and  engine  will  not  continue  to 
be  tested  after  it  has  failed,  (see  note  2) 

611-615  See  OVERDUE. ACTION  lines  563-567. 


IN. ACTION 


626  If  an  outgoing  engine  (one  due  for  replacement) 

has  already  been  identified  by  the  system  (FLAG  is 
greater  than  100) ,  there  is  no  need  to  search  for 
another  engine  to  replace.  Skip  the  following 
statements  and  transfer  control  to  line  646. 

626-630  If  an  engine  has  not  been  identified  for 

replace  the  system  must  initiate  a  search  for 
the  most  eligible  engine.  Since  engines  are 
placed  into  the  TAKE. SET  with  a  priority  code 
attribute  (STATUS) ,  the  most  eligible  engine  will 
be  at  the  beginning  of  the  TAKE. SET.  Lines  62? 
and  630  look  in  the  beginning  of  the  TAKE. SET  and 
find  the  first  engine  that  is  not  TAKEN  and  as¬ 
signs  its  memory  location  to  the  variable* FLAG. 

631-633  If  such  an  engine  has  been  found,  the  outgoing 

engine  has  been  identified  and  control  passes  to 
1 ine  646. 

634  If  there  is  no  eligible  engine  in  the  TAKE. SET  and 

EARLY . OVERHAULS  are  authorized: 

635-638  A  search  is  made  of  the  ALERT. MISSILE. SET  to  find 
the  engine  closest  to  its  RANK . DATE ,  not  CLAIMed, 
and  with  no  STATUS  code  (indicating  an  engine  that 
has  been  selected  for  a  test,  is  overdue,  or 
broken) .  If  such  an  engine  has  been  found,  the 

outgoing  engine  has  been  identified  and  control  is 
passed  to  line  646. 

640-645  If  no  eligible  engine  has  been  identified  for 
replacement,  the  incoming  spare  engine,  if  any 
(indicated  by  MSL  not  equal  to  zero),  is  shipped 
back  to  DEPOT  1  as  a  spare  resource  and  the  process 
is  terminated. 


646-449 


639-662 


663-667 


674-679 


479-682 


Once  the  outgoing  engine  has  been  identified,  a 
check  is  made  (MSL  greater  than  100>  to  see  in  an 
incoming  spare  engine  has  also  been  identified. 
If  so,  control  is  passed  to  line  663. 

If  no  incoming  spare  engine  has  been  identified,  a 
search  of  the  repaired  stocks  is  made  to  locate 
one.  Priority  is  given  for  selection  from  DEP0T1. 
If  its  stock  if  spare  engines  is  equal  to  or 
greater  then  DEP0T2's  (and  not  zero),  the  oldest 
spare  engine  is  selected  from  the  DEPOT!  repaired 
engine  stock.  If  DEP0T2  has  more  spares  than 
DEPOT i  (but  not  zero),  the  oldest  spare  engine  is 
selected  from  the  DEP0T2  repaired  engine  stock. 
If  no  spare  is  available  from  either  stock,  the 
outgoing  engine  is  placed  in  the  TAKE. SET  (if  it 
is  not  already  in  it  and  it  is  not  an 
EARLY . OVERHAUL  engine  £  STATUS  *  NONE  I  ),  and  the 
process  is  terminated. 

If  both  an  outgoing  engine  and  an  incoming  engine 
have  been  identified,  the  outgoing  engine's  CLAIM 
is  set  to  TAKEN  (to  preclude  its  selection  for 
removal  by  another  process)  and  an  ENTER. BASE  is 
scheduled  in  TRANSPORT . DAYS .  (see  note  2) 


Even  though  an  engine  has  been  identified  for 
replacement  by  the  process  IN. ACTION,  it  has  been 
TRANSPORT . DAYS  since  that  has  happened.  During 
this  time,  some  other  engine  at  the  same  base  with 
a  higher  priority  could  have  become  eligible  for 
replacement.  If  so,  and  no  spare  engine  was 
immediately  available  for  its  replacement,  it 
would  have  been  placed  in  the  TAKE. SET.  So  a 
check  must  be  made  of  the  TAKE. SET.  If  it  is 
empty,  there  can  be  no  other  engines  of  a  higher 
priority,  so  the  previously  identified  engine 
(FLAG)  will  be  replaced  (ENG. OUT  =  FLAG)  and 
control  is  passed  to  line  689. 

If  other  engines  are  in  the  TAKE. SET,  it  must  be 
checked  for  higher  priority  engines.  This  is 
accomplished  by  placing  it  in  the  TAKE. SET  (if  it 
is  not  already  there  and  it  is  not  an 
EARLY . OVERHAUL  engine),  to  assume  its  rightful 
place  in  the  "replacement  pecking  order".  Its 
CLAIM  must  first  be  cleared  to  allow  it  to  be 
chosen  from  the  TAKE. SET. 


• '  .>  >.>  , 
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683-687 


A  check  is  then  made  of  the  TAKE. SET  to  select 
the  highest  priority  engine  (at  the  previously 
identified  engine" s  base)  for  replacement.  If  one 
is  found  (which  could  be  the  previously  identified 
one),  its  memory  location  to  the  variable 
ENGINE. OUT. 


(689-718)  These  statements  process  the  outgoing  engine. 


698-693 


694-695 


696-782 


784-789 


711-713 


An  outgoing  engine  identified  for  an  EVIP  test 
(TEST. STATUS  -  EVIP) ,  that  has  not  failed,  is 
shipped  to  the  test  site,  (see  note  2) 

An  engine  selected  for  an  EVI P  test  that  has 
failed  (STATUS  «  BROKE)  is  sent  to  DEP0T1  for 
servicing  instead  of  the  test  site. 

The  counter  for  the  number  of  engines  overdue  or 
broken  (as  appropriate)  is  decremented  by  one. 
The  engine  is  removed  from  the  base  and  the 
counters  only  track  those  on  a  base. 

The  outgoing  engine  is  removed  from  various  on- 
base  set  if  it  is  in  them. 

The  incoming  spare  engine's  location  is  set  to  the 
base  of  the  engine  it  is  replacing,  and  the  engine 
(now  in  an  operational  missile)  is  placed  in  the 
#ALERT  .MI  SSI  LE .  SET . 


Reads  data  from  input  file  SIMU19. 

Continues  on  only  if  there  is  more  data  to  read. 

Reads  in  the  new  servicing  capacity  for  DEPOT 1 
(CAPACITY)  and  the  date  of  the  change  in  CAPACITY. 

Delays  until  change  date. 

Releases  the  number  of  units  of  DEPOT 1  capacity  it 
previously  preempted  (OLD) .  This  gives  the  maxi¬ 
mum  capacity  back  to  the  DEPOT. 

Preempts  CAPACITY  units  of  DEPOT 1  servicing  capa¬ 
city  by  requesting  them  with  a  high  (#1)  priority. 
For  example,  if  the  new  capacity  was  supposed  to 
be  58  units,  it  would  preempt  288-58  or  158  units, 
leaving  58  units  for  the  DEPOT  to  use.  If  158 


aw 


7  38 


733 

pseaiZi 

738-753 

HALT 

839-851 


852 

MfiNIHlxYr 

868 


units  were  not  available  at  this  time,  it  would 
wait  and  preempt  them  as  they  became  available. 

The  new  CAPACITY  is  assigned  to  the  variable  OLD 
to  be  released  in  the  next  change. 

Control  is  passed  back  to  line  741  to  check  for 
further  changes. 


OPACITY  i 


SCHEDULE 


See  DEPOT 1. CAPACITY. SCHEDULE  lines  719-734 


A  sample  of  the  output  generated  by  this  process 
is  presented  in  Appendix  A:  Sample  Output 
Summary.  The  output  has  been  reformatted  for  in¬ 
clusion  in  this  paper.  The  content,  however,  has 
not  changed  from  that  generated  by  this  process. 


The  counters  BROKEN UM  and  OVERNUM  are  the  number 
of  engines  broken  and  overdue  during  the  life  of 
the  system.  8R0KESU1  and  OVERSUM  are  the  total 
amount  of  time  broken  and  overdue  accumulated  by 
these  engines.  The  system  generated  routines  used 
track  these  values  double-counts  the  engines  in 
question.  One  is  counted  when  an  engine  is  added 
to  the  counter  and  one  is  counted  when  the  same 
engine  is  subtracted  from  the  counter.  Thus  the 
actual  number  of  engines  broken  or  overdue  is  one- 
half  of  that  indicated  by  the  counter.  Variables 
B2  and  02  contain  the  correct  numbers. 
BR0KESUM/B2  and  OUERSUM/02  give  the  average  time 
broken  or  overdue. 

After  all  the  statistics  are  printed  out  the 
program  is  terminated. 


The  month  being  processed  <  the  variable  COUNT)  is 
incremented  each  time  the  process  is  activated 
<  each  month) . 


861-862  The  local  variables  are  reset  for  each  months 

cal  eolations. 

863-876  The  average  age  of  each  type  of  engine  in  the 

ALERT. MISSILE. SET  is  calculated  each  month.  Each 
engine  in  the  ALERT .MISSILE. SET  is  examined  and 
its  age  (current  time  -  START. DATE)  is  summed  in 
the  variables  TOTAL  1  (-for  101's)  or  T0TAL4  (-for 
104' s> .  The  number  o-f  each  type  o-f  engine  is 

tabulated  in  the  variables  DIVISOR 1  and  DIVIS0R4. 
The  summed  ages  o-f  each  type  are  then  divided  by 
the  total  number  o-f  each  type,  giving  average 

ages.  These  values  are  then  assigned  to  the 

AVERAGE. AGE  array  for  that  month.  To  preclude 

division  by  zero  (if  there  are  no  engines  of  a 

given  type),  any  zero-valued  divisor  is  set  equal 
to  1. 

877  The  maximum  number  of  engine  required  by  the 

system  over  the  last  month  (see  note  1)  is 

assigned  to  the  SPARES  array  for  that  month. 

Since  this  process  is  activated  on  the  first  day 
of  each  month,  the  statistics  given  for  that  month 
are  derived  from  and  apply  to  the  previous  month's 
data.  The  statistics  in  the  model ,  as  those  in 
the  real  world,  are  always  a  month  behind. 

878-881  If  the  maximum  number  of  engine  required  for  this 
month  is  greater  than  any  previous  month,  the 
increase  in  engines  required  is  recorded  in  the 
SPARES  array  for  the  month,  and  this  month's 
spares  requirement  is  saved  in  the  variable  LAST  1 
to  be  used  as  the  new  comparison  value  in  the 
upcoming  months. 

882  All  monthly  statistics  are  reset  to  zero. 


SHIP 


887-888 


The  time  the  engine  will  arrive  at  its  destination 
(the  current  simulation  time  Ctime.vl  plus 
transportation  time  (TRANSPORT. DAYS I  )  is  assigned 
to  the  engine's  ARRIVAL  attribute,  and  the 
engine's  SHIPPING. STATUS  is  changed  to  reflect  its 
shipment  (INTRANSIT).  (see  note  2) 
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896-897 


Deployment  base  numbers  range  -from  3  to  8,  but  the 
SHIP.hlSSILE  process  ranges  them  -from  1  to  6 ,  this 
line  adjusts  the  di-f-ference. 

The  incoming  missile  arrives  and  is  placed  in  the 
ALERT .MISSILE. SET  as  an  operational  asset. 


983-906 


If  the  engine  is  not  already  counted  as  a  spare  or 
as  requiring  a  spare,  it  is  added  to  the  spares 
requirement  counter  ( NUM. SPARE) ,  and  its 
SHIPPING. STATUS  is  changed  to  indicate  it  is  a 
SPARE.  <see  note  i> 


912-915 


If  the  engine  was  previously  counted  as  a  spare 
(SPARE. STATUS  *  SPARE),  its  SPARE. STATUS  is 
changed  to  indicate  it  is  not  a  spare,  and  the 
spares  counter  (NUM. SPARES)  is  decremented  by  one. 


921-935 


This  routine  is  called  when  an  engine  is  in  one  of 
the  DEPOT'S  REPAIRED. SETs  but  the  particular  set 
is  not  known.  This  is  an  idiosyncrasy  of  the 
SIMSCR1FT  language  where  a  entity  is  placed  in  a 
subscripted  set  (one  of  the  sets  owned  by  the 
DEPOTS),  it  cannot  be  directly  examined  to  deter¬ 
mine  which  set  it  is  in.  Hithout  this  knowledge, 
it  cannot  be  successfully  removed  from  the  set. 
This  routine  overcomes  this  system  fault  by 
examining  each  set  until  it  locates  the  engine  in 
question.  It  then  can  be  removed  since  it  is  now 
known  which  set  it  is  in. 


NOTE  1 


The  model  mas  designed  to  indicate,  at  any  given  time, 
the  number  o-f  engines  that  are  being  used  as  spares  engines 
or  require  a  spare  engine.  If  an  engine  is  being  trans¬ 
ported  from  a  base  to  the  DEPOT  for  repair,  it  is  not  avail¬ 
able  for  use  as  an  operational  asset  and  thus  is  being  used 
as  a  spare  engine.  The  same  is  true  for  engines  selected 
for  EVIP  tests,  they  are  unavailable  for  operational  use 
while  being  transported  to  and  from  the  test  site  and  Mhile 
in  the  test  program.  They  also  require  a  spare  engine  to 
replace  them  in  the  missile  they  Mere  removed  from.  Engines 
undergoing  maintenance  and  servicing  are  also  being  used  as 
spares. 

If  a  demand  for  a  spare  engine  exists^  that  cannot  be 
immediately  filled  <as  Mhen  an  engine  on  base  fails  and 
there  are  no  spares  on  that  base) ,  a  demand  for  a  spare 
engine  is  created  beyond  the  number  of  spare  engines  being 
used  as  spares.  This  demand  still  exists  Mhile  the  replace¬ 
ment  engine  is  being  shipped  to  the  base,  but  has  not  yet 
arrived. 

Engines  not  counted  as  spares  include  those  being 
transported  to  meet  a  demand  <to  do  so  Mould  double-count 
the  spares  requirement,  once  for  the  engine  being  shipped 
and  once  for  the  demanding  engine).  Also  excluded  are  OTL 
test  engines.  Since  the  airframe  goes  Mith  the  engine  for 
an  OTL  test,  there  is  no  demand  for  a  spare,  nor  a  place  for 


a  spar*  to  reside  (as  with  the  EVIP  tsst  engine) .  Finally 
those  engines  in  missiles  not  yet  deployed  to  bases  are  not 
being  used  as  spares,  nor  creating  a  demand  for  a  spar*. 

tffllE  2 

To  simulate  the  shipment  of  an  engine  or  missile  from 
on*  place  to  another,  the  PROCESS  that  controls  the  receiv¬ 
ing  activity  for  the  engine  is  scheduled  TRANSPORT. DAYS  (the 
number  of  days  it  takes  to  ship  an  engine  from  on*  place  to 
another)  later.  This  simulates  the  time  delay  due  to  trans¬ 
portation.  While  the  engine  is  being  "transported",  it  is 
unavailable  for  processing  by  any  other  activity.  To  indi¬ 
cate  this,  its  SHIPPING. STATUS  is  set  to  INTRANSIT,  and  the 
date  it  Mill  arrive  at  its  next  activity  is  assigned  to  its 
ARRIVAL. TIME  attribute.  Both  of  these  actions  are  accom¬ 
plished  by  the  SHIP  routine. 


Appendix  D*  Input  File*  S1MU7  and  SIMU9 


SIMU7 


The  following  file  is  the  first  combination  of  the  thirty- 
two  different  SIMU7  files.  These  files  are  used  to  change 
the  independent  variables  in  the  simulation.  The  values  on 
the  left  side  of  the  file  are  changed  to  reflect  the 
specifications  shown  in  TABLE  VII. 


S01 

4  DAYS . REQUI RED .TO .TRANSPORT . UNIT 

40  DAYS. FOR. OTL. TESTING 

40  DAYS. FOR. EV IP. TESTING 

0.1  LOSS . RATE . FOR .OTL .TESTING 

30  * . OF . DAYS .NEEDED . FOR . TEST . REFURBI SHMENT 

30  #. OF. DAYS. NEEDED. FOR. FULL. OVERHAUL 

6  0 . OF . DAYS .NEEDED . FOR . LIMITED . OVERHAUL 

30  0. OF. DAYS. NEEDED. FOR. 101 .TO. 10 4. CONVERSION 

0.0  MISSILE. FAILURE.  RATE 


>-V.V.  ,*  \.  w  \«~‘  .'•T>'»>-*.VV  \-i  .-V  \%  \  *»  \-rv 


SIMU9 

This  -f i  1  •  reflects  values  -for  factors  that  Mill  be  con¬ 
sidered  constants  for  this  research  effort.  Future  research 
efforts  may  change  these  values  based  on  the  assumptions 
made  in  their  research. 


1  MONTH .  SYSTEM .  STARTS 

1  DAY. SYSTEM. STARTS 

1981  YEAR. SYSTEM. STARTS 

31  DAY.  CONFERS  IONS.  END 

1  MONTH.  CONVERSIONS.  END 

1991  YEAR.  CONVERSIONS.  END 

1  MONTH.  SYSTEM.  ENDS 

1  DAY. SYSTEM. ENDS 

2081  YEAR. SYSTEM.  ENDS 

1  MONTH.  0CA1.C.  OPENS.  FOR.  BUSINESS 

1  DAY. OCALC. OPENS. FOR. BUSINESS 

1989  YEAR. OCALC. OPENS. FOR. BUS I NESS 

1  MONTH.  ENGINES.  BEGIN.  TO.  BE.  CONVERTED.  TO.  104'S 

1  DAY. ENGINES. BEGIN. TO. BE. CONVERTED. TO. 104' S 

1988  YEAR. ENGINES. BEGIN. TO. BE. CONVERTED. TO. 104'S 

1  STREAM .NUMBER . 1 

2  STREAM. NUMBER. 2 

3  STREAM .NUMBER . 3 

4  STREAM  .NUMBER .  4 

5  STREAM. NUMBER.  5 

912  NUMBER.  OF.  DAYS  .WARRANTED.  LIFE.  FOR.  A.  101.  ENGINE 
1825  NUMBER . OF . DAYS .WARRANTED .LIFE. FOR . A . 104. ENGINE 

6  NUMBER. OF. BASES 

115  NUMBER. OF. SPARES. ALLOWED. IN. SYSTEM 

286  BASE . 1 .MI SSI LE . REQUI REMENTS 

286  BASE. 2. MISSILE. REQUI REMENTS 

286  BASE. 3. MISSILE. REQUI REMENTS 

286  BASE. 4. MISSILE. REQUI REMENTS 

286  BASE. 5. MISSILE. REQUI REMENTS 

285  BASE. 6. MISSILE. REQUI REMENTS 

200  MAXIMUM. MONTHLY. CAPACITY. FOR. DEPOT  1 

200  MAXIMUM. MONTHLY. CAPACITY. FOR. DEP0T2 

0  EARLY. OVERHAUL. OK? (YES* 10  ,NO*0> 
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Appendix  Ei  Program  Lietin 


"ALCM  ENGINE  SIMULATION  PROGRAM 
" < BY  D.  RICKARD  it  T.  SCHOMMER) 


2 

3 

4 

5 


PREAMBLE 
NORMALLY  MODE 


IS  INTEGER 


"REDEFINE  VARIABLES  TO  INSURE  UNIQUE  VALUES  FOR  SIMILAR 
"VARIABLE  NAMES 


6 

DEFINE 

SPARES 

TO 

MEAN 

S2PARES 

7 

DEFINE 

SPARES.  COUNT 

TO 

MEAN 

CSPARES 

S 

DEFINE 

ENGINE. PRODUCTION 

TO 

MEAN 

PENGINE 

9 

DEFINE 

START. YR 

TO 

MEAN 

S1TART.YR 

10 

DEFINE 

START .MO 

TO 

MEAN 

S2TART.M0 

11 

DEFINE 

START. DATE 

TO 

MEAN 

D.  START.  DATE 

12 

DEFINE 

STREAM4 

TO 

MEAN 

4STREAM4 

13 

DEFINE 

STREAMS 

TO 

MEAN 

3 STREAMS 

14 

DEFINE 

CONVERT  .YR 

TO 

MEAN 

S1MITCH.YR 

19 

DEFINE 

CONVERT  .MO 

TO 

MEAN 

S2MITCH.MO 

1 6 

DEFINE 

CONVERT.  DAY 

TO 

MEAN 

S3M ITCH. DAY 

17 

DEFINE 

STREAM  1 

TO 

MEAN 

1  STREAM  1 

IS 

DEFINE 

STREAM2 

TO 

MEAN 

2STREAM2 

19 

DEFINE 

TEST. PICK 

TO 

MEAN 

4TEST.PICK 

20 

DEFINE 

DATE. EXPIRES 

TO 

ME**I 

SDATE. EXPIRES 

21 

DEFINE 

ENGINE.  ID. NUMBER 

TO 

MEAN 

E. ID. NUMBER 

22 

DEFINE 

MI SSI LE . PRODUCTI  ON 

TO 

MEAN 

MISL.PROD 

23 

DEFINE 

BASE  .MI  SSI  LE .  COUNTER 

TO 

MEAN 

C2BASE.MSL 

24 

DEFINE 

REPAIR 

TO 

MEAN 

R1EPAIRED 

26 

DEFINE 

NUMBER 

TO 

MEAN 

NUM 

27 

DEFINE 

ENGINE. IN 

TO 

MEAN 

ENG. IN 

26 

DEFINE 

ENGINE.  OUT 

TO 

MEAN 

ENG. OUT 

29 

DEFINE 

CONVERSION 

TO 

MEAN 

CGMV 

30 

DEFINE 

NUMBER. BASES 

TO 

MEAN 

NUM. BASE 

31 

DEFINE 

TRANSPORT .  DAYS 

TO 

MEAN 

TRANS .  DAYS 

32 

DEFINE 

MAINTENANCE .  RECORD 

TO 

MEAN 

MAIN.REC 

33 

DEFINE 

MORK . STATI ONS .  IN . USE 

TO 

MEAN 

IWSTATI ON 

34 

DEFINE 

SPARE. STATUS 

TO 

MEAN 

SPSTAT 

39 

DEFINE 

CONVERT 

TO 

MEAN 

ChWRT 

34 

DEFINE 

ENGINE .  SEQUENCE  .NUMBER 

TO 

MEAN 

E.SEQ.NUM 

37 

DEFINE 

DEPOT 1 . CAPACITY . SCHEDULE 

TO 

MEAN 

D1SCHED 

3G  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
39  PROCESSES 


40 

41 

42 

43 

44 
49 
4  6 


INCLUDE 


EVERY 

EVERY 

EVERY 

EVERY 


DEPOT 1 . CAPACITY . SCHEDULE , 
DEP0T2 . CAPACITY . SCHEDULE , 

SPARE . ENG I NE . GENERAT I ON 
ENTER. BASE  HAS  Al,  AN  A2 

MAINTENANCE  HAS  A  Bl,  A  B2 

SHIP. MISSILE  HAS  A  Cl 

TEST  HAS  A  D1 


#  * 


PREAMBLE  CONTINUED 
47  PROCESSES 


46 

49 

30 

31 

32 
S3 
34 


INCLUDE 


COWERT, 

CREATE.  ENGINE, 
ENGINE .  PRODUCTION , 
HALT 

MONTHLY . STATI ST I CS , 
MI SS I LE . PRODUCT I  ON , 
SCHEDULE . CONVERSION , 


S3 

TEST. GENERATION 

34 

EVERY 

DEPLOY 

HAS 

A 

Tl,  A  T2 

37 

EVERY 

IN. ACTION 

HAS 

A 

Ql,  A  Q2 

38 

EVERY 

FAILURE.  ACTION 

HAS 

A 

R1 

39 

EVERY 

OVERDUE.  ACTION 

HAS 

A 

SI 

40 

EVERY 

TEST. PICK 

HAS 

A 

F0 

41 

EVERY 

TRANSPORT 

HAS 

A 

G1,A  62, 

A 

03 

62  ' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


43 

PERMANENT 

ENTITIES 

44 

EVERY 

DEPOT 

OHNS 

A 

REPAIRED. SET 

45 

EVERY 

BASE 

HAS 

A 

BASE .MI SSI LE . COUNTER , 

44 

A 

BASE.MISSILE.RQMT 

47 

THE  SYSTEM 

OHNS 

AN  ALERT. MISSILE. SET, 

48 

A 

PRODUCTION. POOL, 

49 

A 

TAKE. SET, 

70 

A 

TEST. SET 

71 

"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

72 

GENERATE  LIST  ROUTINES 

73 

TEMPORARY 

ENTITIES 

74 

EVERY 

ENGINE 

HAS 

AN 

ARRIVAL. TIME, 

73 

A 

CLAIM, 

74 

AN 

ENGINE.  ID. NUMBER, 

77 

AN 

DATE. EXP I RES, 

78 

A 

LOCATION, 

79 

A 

RANK. DATE, 

80 

A 

SHIPPING. STATUS, 

81 

A 

START.  DATE, 

82 

A 

SPARE. STATUS, 

83 

A 

STATUS, 

84 

A 

TEST. STATUS, 

83 

A 

TYPE, 

84 

A 

TYPE. SERVICE  AND 

87 

MAY  BELONG 

TO 

AN 

ALERT. MISSILE. SET, 

88 

A 

PRODUCT I ON. POOL, 

89 

A 

REPAIRED. SET, 

90 

A 

TAKE. SET, 

91 

A 

TEST. SET 

92 

INHIBIT  LIST  ROUTINES 

93  ' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

94  DEFINE  ALERT  .MISSILE.  SET  AS  A  SET  IVWKED  BY 
LON  RANK. DATE 

93  DEFINE  TAKE. SET  AS  A  SET  RANKED  BY  HIGH  STATUS, THEN  BY 
LON  DATE. EXPIRES 


/  / 


PREAMBLE  CONTINUED 
94  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

97  RESOURCES  INCLUDE  WORK. STATION 

98  ' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


99 

DEFINE 

LOC. REPAIRED. SET 1 

TO 

MEAN 

1 

188 

DEFINE 

LOC. PRODUCT I  ON 

TO 

MEAN 

9 

181 

DEFINE 

YES 

TO 

MEAN 

18 

182 

DEFINE 

INTRANSIT 

TO 

MEAN 

28 

183 

DEFINE 

BOEING 

TO 

MEAN 

38 

184 

DEFINE 

OTL.TEST. SITE 

TO 

MEAN 

48 

185 

DEFINE 

EVIP.TEST.  SITE 

TO 

MEAN 

58 

184 

DEFINE 

TAKEN 

TO 

MEAN 

78 

187 

DEFINE 

LIMITED 

TO 

MEAN 

188 

188 

DEFINE 

FULL 

TO 

MEAN 

288 

189 

DEFINE 

REPAIR 

TO 

MEAN 

388 

118 

DEFINE 

REFURB 

TO 

MEAN 

488 

111 

DEFINE 

CONVERSION 

TO 

MEAN 

588 

112 

DEFINE 

NONE 

TO 

MEAN 

488 

113 

DEFINE 

DUE 

TO 

MEAN 

418 

114 

DEFINE 

BROKE 

TO 

MEAN 

438 

115 

DEFINE 

SPARE 

TO 

MEAN 

458 

114 

DEFINE 

OTL 

TO 

MEAN 

788 

117 

DEFINE 

EVIP 

TO 

MEAN 

888 

118 

DEFINE 

JTA 

TO 

MEAN 

988 

1 19  "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


128 

DEFINE 

AVERAGE. AGE 

AS 

AN 

INTEGER, 

2-DIMENSIONAL 

ARRAY 

121 

DEFINE 

MAINTENANCE . 

RECORD 

AS 

AN 

INTEGER, 

2-DIMENSI ONAL 

ARRAY 

122 

DEFINE 

WORK.  STATIONS.  IN, 

.USE 

AS 

AN 

INTEGER, 

2-DIMENSIONAL 

ARRAY 

123 

DEFINE 

SPARES 

AS 

AN 

INTEGER, 

2-DIMENSIONAL 

ARRAY 

124 

DEFINE 

TERM 

AS 

AN 

INTEGER, 

1 -DIMENSIONAL 

ARRAY 

125 

DEFINE 

MAY. CONVERT 

AS 

AN 

INTEGER, 

I -DIMENSIONAL 

ARRAY 

12 6  ' 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

127  DEFINE  START. DAY,  START  .MO,  START. YR, 

128  END. DAY,  END. MO,  END.YR, 

129  OPEN. DAY,  OPEN. MO,  OPEN.YR, 

138  COWERT . DAY ,  COVERT  .MO,  CONVERT. YR, 

131  DAY . COWERS  I ONS . END ,  MO. CONVERSIONS. END, 

YR.  COWERS  IONS.  END, 

132  STREAM  1,  STREAM2,  STREAM3,  STREAM4,  STREAMS 

133  AS  INTEGER  VARIABLES 

134  DEFINE  COWERS  I  ON.  TIME,  FULL-TIME,  LIMITED. TIME, 

REFURB.TIME, 

135  NUMBER. BASES,  NUMBER . SPARES , 

OCALC. CAPACITY,  WILLI AMS. CAPACITY, 

134  TOTAL. MONTHS,  TRANSPORT . DAYS , 

137  EVIP.TEST ,  OTL.TEST,  DESTROYED,  COUNT, 

138  NUM. BROKEN,  NUM. OVERDUE,  NUM. SPARE, 

139  ENGINE. SEQUENCE. NUMBER,  EARLY . OVERHAUL . OK 

148  AS  INTEGER  VARIABLES 

141  DEFINE  RECOVERY . FAI LURE . RATE ,  START. DATE,  FAIL. RATE, 

142  DATE. EXP I RES, RANK. DATE  AS  REAL  VARIABLES 


/  / 


143 

144 

145 
144 

147 

148 

149 

198 

191 

192 

193 

194 

199 
194 

197 

198 

199 

148 

141 

142 

143 

144 

149 
144 

147 

148 

149 

178 

171 

172 

173 

174 

179 
174 

177 

178 

179 
188 
181 
182 

183 

184 
189 
184 


PREAMBLE  CONTINUED 
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
TALLY 

MAX. PER. MONTH  AS  THE  MONTHLY  MAXIMUM, 


LIFE .MAX 

ACCUMULATE 

BROKENUM 

BROKESUM 

ACCUMULATE 

OVERNUM 

OVERSUM 


AS  THE 
OF 

AS  THE 
AS  THE 
OF 


AS 

AS 

OF 


THE 

THE 


MAXIMUM 
NUM.  SPARE 

NUMBER, 

SUM 

NUM. BROKEN 


SUM 

NUM. OVERDUE 


END 

"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


MAIN 

DEFINE  I,J  AS  INTEGER  VARIABLES 

DEFINE  RZ, INFILE  AS  TEXT  VARIABLES 

"  RZ  IS  USED  TO  ACCOUNT  FOR  INPUT  FILE  COPMENTS 

USE  7  FOR  INPUT  USE  8  FOR  OUTPUT 

READ  INFILE 

PRINT  1  LINE  WITH  INFILE  THUS 

SOURCE  FILE  IS  XXXX 

LET  ENGINE. SEQUENCE. NUMBER  -  1 

RESERVE  TERM<X)  AS  4  RESERVE  MAY.COWERT<X>  AS  2 

READ  TRANSPORT .DAYS,RZ  ,0TL.TEST ,RZ  ,EVIP.TEST ,RZ  , 
RECOVERY . FAI LURE . RATE , RZ 
READ  REFURB .  T I  ME ,  RZ 

READ  FULL. TIME ,  RZ ,  LIMITED. TIME,  RZ  ,  CONFERS  I  ON.  T I  ME,  RZ  , 
FAIL. RATE, RZ 
USE  9  FOR  INPUT 

READ  START  .MO ,  RZ  ,  START .  DAY ,  RZ  ,  START .  YR ,  RZ 

READ  DAY .  COWERS  I ONS .  END ,  RZ  ,MQ .  CONVERSI ONS .  END ,  RZ  , 

YR . CONVERS I ONS . END , RZ 

READ  END . MO , RZ , END . DAY , RZ , END . YR , RZ , OPEN . MO , RZ , 

OPEN. DAY, RZ 

READ  OPEN .  YR ,  RZ  ,  CONVERT  .MO ,  RZ  ,  COVERT .  DAY ,  RZ  , 
COWERT.YR,RZ 

READ  STREAM 1 , RZ , STREAM2 , RZ , STREAM3 , RZ , STREAM4 , RZ , 
STREAMS, RZ 

READ  TERM<  1)  ,  RZ  ,TERM<  4)  ,  RZ  .NUMBER .  GASES ,  RZ  , 

NUMBER. SPARES, RZ 

LET  TOTAL. MONTHS  -  <  (END.YR-START ,YR>  +  1)  X  12+ 

<  END .MO-START .MO>  +  1 

RESERVE  MAINTENANCE . RECORD< X , X)  AS  TOTAL. MONTHS  BY  5 
RESERVE  AVERAGE. AGE <X,X>  AS  TOTAL. MONTHS  BY  2 
RESERVE  SPARES(X,X>  AS  TOTAL. MONTHS  BY  2 
RESERVE  WORK. STATIONS. IN. USE(X,X>  AS  TOTAL. MONTHS  BY  2 


94 


187  CREATE  EVERY  WORK .STATION < 2)  CREATE  EVERY  DEPOT<2) 

188  CREATE  EVERY  BASE (NUMBER . BASES) 

189  FOR  EACH  BASE 

198  READ  BASE. MISSILE. ROMTCBASE) ,RZ 

191  READ  MILLIM1S.  CAPACITY  fRZ,OCALC.  CAPACITY  ,RZ, 

EARLY . OVERHAUL . OK , R2 

192  LET  U.MORK.STATION(1>  -  MILL  I  AMS.  CAPACITY 

193  LET  U.MORK.  STATION  (2)  -  OCALC. CAPACITY 

194  CALL  ORI  SIN.  R<  START  .MO,  START.  DAY,  START.  YR> 

195  FOR  I  -  START. YR  TO  END.YR 
194  DO  FOR  J  -  1  TO  12 

197  ACTIVATE  A  MONTHLY. STATIST ICS  AT  DATE . F < J , 1 , 1 > 

198  LOOP 

199  ACTIVATE  A  HALT  AT  DATE. F< END. MO, END. DAY, END. YR> 

208  SCHEDULE  A  SPARE. ENGINE. GENERATION  NON 
201  ACTIVATE  A  TEST. GENERATION  NOM 

282  ACTIVATE  A  MISSILE.  PRODUCT  I  ON  NOM 

283  ACTIVATE  AN  ENGINE. PRODUCTION  NOM 
204  ACTIVATE  A  SCHEDULE. CONVERSION  NOM 
285  SCHEDULE  A  DEPOT  1  .CAPACITY. SCHEDULE  NOM 
204  SCHEDULE  A  DEP0T2. CAPACITY. SCHEDULE  NOM 
207  START  SIMULATION 
288  END 


213  PROCESS  MAINTENANCE  (MSL,  DEPOT  .NUMBER) 

214  DEFINE  MSL ,  DEPOT  .NUMBER  , INDEX  AS  INTEGER  VARIABLES 
219  LET  SHI PPING . STATUS<MSL>  -  NONE 

214  LET  INDEX  -  TYPE. SERVICE (MSL)/ 199 

217  ADD  1  TO  MAINTENANCE. RECORD< COUNT , INDEX) 

218  IF  INDEX  NE  1 

219  LET  INDEX  *  2 
229  AUAYS 

221  IF  TIME.V  >-  OATE . F < COVERT . MO , CONVERT . DAY , CONVERT . YR) 

222  AND  TYPE<MSL>  *  191  AND  MAY .  CONVERT <  INDEX)  >  9 

223  LET  TYPE.SERVICE(MSL)  -  CONVERSION 

224  LET  DEPOT  .NUMBER  -  1 

229  SUBTRACT  1  FROM  MAY .  CONVERT <  INDEX) 

224  ALWAYS 

227  REQUEST  1  WORK.  STATION  (DEPOT.  NUMBER) 

228  ADO  1  TO  WORK.  STATIONS.  IN.  USE<  COUNT,  DEPOT  .NUMBER) 

229  IF  TYPE.SERVICE(MSL)  -  FULL  OR  TYPE.  SERVICE  (MSL)  -REPAJ- 
239  WORK  FULL .TIME  DAYS 

231  LET  TYPE.SERVICE(MSL)  *  LIMITED 

232  ELSE 

233  IF  TYPE. SERVICE (MSL)  ■  LIMITED 

234  WORK  LIMITED. TIME  DAYS 

239  LET  TYPE.SERVICE(MSL)  «  FULL 

234  ELSE 

237  IF  TYPE.SERVICE(MSL)  -  CONVERSION 

238  ADO  1  TO  MAINTENANCE  .  RECORD <  COUNT  1 9) 

239  WORK  CONVERSION. TIME  DAYS 

249  LET  TYPE(MSL)  »  194 

241  LET  TYPE .  SERVI CE(MSL)  -  LIMITED 

242  ELSE 

243  WORK  REFURB.TIME  DAYS 

244  LET  TYPE . SERVI CE(MSL)  -  LIMITED 

249  ALWAYS 

244  ALWAYS 

247  ALWAYS 

248  RELINQUISH  1  WORK.  STAT 1 0N<  DEPOT  .NUMBER) 

249  CALL  DATE(MSL) 

299  CALL  SUBTRACT. FROM. SPARE. COUNT  GIVING  MSL 

291  IF  LOCATI ON(MSL)  -  LOC. PRODUCT I ON 

292  CALL  SHIP  GIVING  MSL 

293  CALL  SUBTRACT .  FROM .  SPARE .  COUNT  GIVING  MSL 

294  WAIT  TRANSPORT . DAYS  DAYS 

299  LET  SHI  PPING.  STATUS(MSL)  -  NONE 

294  FILE  THIS  MSL  IN  THE  PRODUCTION. POOL 

297  RETURN 

298  ALWAYS 


"  PROCESS  MAINTENANCE  CONTINUED 

259  IF  TEST. STATUS (MSL)  -  OTL 

2 60  LET  TEST  .STATUS<MSL>  -  NONE 

261  CALL  SHIP  GIVING  MSL 

262  SCHEDULE  A  DEPLOY (MSL, LOCATION (MSL) )  IN 
TRANSPORT . DAYS  DAYS 

263  LET  LOCATION(MSL)  -  LOC. PRODUCT I ON 

264  ELSE 

263  LET  TEST . STATUS(MSL)  -  NONE 

266  LET  LOCATI ON < MSL)  -  DEPOT. NUMBER 

267  IF  N. REPAIRED. SET < 1)  ♦  N. REPAIRED. SET (2)  -  6 

268  IF  N. TAKE. SET  >  8  OR  EARLY . OVERHAUL . OK  -  YES 

269  SCHEDULE  AN  IN.ACTION(MSL)  NON 

270  ELSE 

271  GO  HERE 

272  ALMAYS 

273  ELSE 

274  'HERE' 

.  275  FILE  THIS  MSL  IN  REPAIRED.  SET  (DEPOT.  NUMBER) 

276  ACTIVATE  AN  IN. ACTION  NON 

277  ALMAYS 

278  ALMAYS 

279  END 


282  PROCESS  SPARE. ENGINE. GENERATION 

283  DEFINE  I,J,K,L  AS  INTEGER  VARIABLES 

284  FOR  I  -  1982  TO  1983 

285  DO  FOR  J  -  1  TO  12 
284  DO  FOR  K  ■  1  TO  5 

287  DO 

288  IF  L  -  NUMBER. SPARES 

289  RETURN 

298  ALWAYS 

291  WAIT  DATE.F( J,KX5+RAND1  .F(-2,2,STREAM4)  ,  I>- 
TIME.V  DAYS 

292  CREATE  AN  ENGINE 

293  LET  TYPE .  SERVI  CE<  ENGINE)  -  LIMITED 

294  LET  TYPE (ENGINE)  -  181 

295  LET  ENGINE. I D.NUMBER< ENGINE)  - 
ENGINE .  SEQUENCE  .NUMBER 

296  LET  TEST .  STATUS  <  ENG  I NE)  -  NONE 

297  ADD  1  TO  ENGINE. SEQUENCE. NUMBER 

298  CALL  DATE (ENGINE) 

299  LET  LOCATION  (ENGINE)  -  LOC .  REPAI  RED .  SET  1 

388  IF  N. REPAI RED. SET( 1)  ♦  N. REPAI RED. SET (2)  -  8 

381  IF  N. TAKE. SET  >  8  OR  EARLY . OVERHAUL . OK  -  YES 

382  SCHEDULE  AN  IN.ACTI0N( ENGINE)  NOW 

383  ELSE 

384  GO  HERE 

385  ALWAYS 

386  ELSE 

387  'HERE' 

388  *  FILE  THIS  ENGINE  IN  REPAI  RED .  SET (  1) 

389  ACTIVATE  AN  IN.  ACT  I  ON  NOW 

318  ALWAYS 

311  ADD  1  TO  L 

312  LOOP 

313  LOOP 

314  LOOP 

315  END 

316 

317 

318  PROCESS  TEST . GENERATI ON 

319  DEFINE  I,  NUMBER. TESTS, TEST. DAYS, TEST. TYPE  AS 
INTEGER  VARIABLES 

328  USE  11  FOR  INPUT 

321  READ  NUMBER. TESTS 

322  FOR  I  »  1  TO  NUMBER. TESTS 

323  DO 

324  READ  TEST. DAYS, TEST. TYPE 

325  ACTIVATE  A  TEST. PICK (TEST. TYPE)  IN  TEST. DAYS  DAYS 

326  LOOP 

327  END 


330  PROCESS  TEST . PI CK<TYPETEST> 

331  DEFINE  TYPETEST, PICK  AS  INTEGER  VARIABLES 

332  FOR  EACH  ENGINE  OF  ALERT .MISSILE. SET, 

WITH  TEST. STATUS< ENGINE)  ■  ,  JNE 

333  AND  CLAIM< ENGINE)  NE  TAKEN,  FIND  PICK  -  ENGINE 

334  LET  TEST. STATUS< PICK)  -  TYPETEST 

335  IF  TYPETEST  ■  EVIP 

334  IF  N. REPAIRED. SET < 1)  ♦  N. REPAIRED. SET < 2)  >  0  AND 
N. TAKE. SET  -  0 

33?  SCHEDULE  AN  IN.ACTIGN<0 ,PICK)  NOW 
33G  ELSE 

339  IF  PICK  IS  NOT  IN  TAKE. SET 

340  FILE  THIS  PICK  IN  THE  TAKE. SET 

341  ACTIVATE  AN  IN. ACTION  NOW 

342  ALWAYS 

343  ALWAYS 

344  CALL  ADD. TO. SPARE. COUNT  GIVING  PICK 

343  ELSE 

34 4  IF  STATUS(PICK)  -  DUE 

347  SUBTRACT  1  FROM  NUM. OVERDUE 

34G  LET  STATUS<  PI CK)  -  NONE 

349  ALWAYS 

330  REMOVE  THIS  PICK  FROM  THE  ALERT  .MISSILE.  SET 

331  IF  PICK  IS  IN  TAKE. SET 

332  REMOVE  THIS  PICK  FROM  TAKE. SET 

333  ALWAYS 

354  IF  TYPETEST  -  OTL 

335  CALL  SHIP  GIVING  PICK 

336  ACTIVATE  A  TEST<PICK>  IN  TRANSPORT . DAYS  DAYS 

337  ELSE  "  JTA 

356  ADD  1  TO  DESTROYED 

339  ALWAYS 

360  ALWAYS 

361  END 


364  PROCESS  MISSILE. PRODUCT I ON 

365  DEFINE  R2  AS  A  TEXT  VARIABLE 

366  DEFINE  I ,  J , K , NUMBER  .TO .  SEND  yMSL . PRODUCTION  .NUMBER , 

367  DAY  AS  INTEGER  VARIABLES 

368  USE  13  FOR  INPUT 

369  READ  RZ 

378  FOR  I  *  1981  TO  1986 

371  DO 

372  READ  RZ 

373  FOR  J  -  1  TO  12 

374  DO 

375  READ  MSL.  PRODUCT  I  ON.  NUMBER 

376  IF  MSL. PRODUCTION. NUMBER  -  8  CYCLE  ALWAYS 

377  LET  NUMBER.  TO.  SEND  -TRUNC .  F<MSL .  PRODUCTION  .NUMBER/ 4) 

378  FOR  K  >  1  TO  3 

379  DO 

388  LET  DAY  *  <KX7>  ♦  RWDI  .F<-2,2,STREAM4> 

381  SCHEDULE  A  SHIP  .MI  SSI  LE< NUMBER. TO  .SEND)  AT 
DATE.FC J(DAY,1) 

382  LOOP 

383  SCHEDULE  A  SH  IP.  MI  SSI  LE<  MSL.  PRODUCT  I  ON.  NUMBER- 
NUMBER.  TO.  SENDX  3)  AT  DATE.F<  J,28, 1) 

384  LOOP 

385  LOOP 

386  END 

387 

388 

389 

398  PROCESS  SHIP.MISS1LE<NUMBER> 

391  DEFINE  I  .NUMBER, ENGINE  AS  INTEGER  VARIABLES 

392  DEFINE  J  AS  A  SAVED  INTEGER  VARIABLE 

393  FOR  I  **  1  TO  NUMBER 

394  DO 

395  'TRY .AGAIN' 

396  IF*  PRODUCT  I  ON.  POOL  IS  NOT  EMPTY 

397  REMOVE  FIRST  ENGINE  FROM  PRODUCT  I  ON.  POOL 

398  ELSE 

399  WAIT  1  DAY 

488  60  TRY. AGAIN 

48 1  ALWAYS 

482  'CK' 

483  IF  BASE.MISSILE.RGMT(J+ 1>  >  BASE. MISS I LE. COUNTER < J+ 1> 

484  CALL  SHIP  GIVING  ENGINE 

485  SCHEDULE  A  DEPLOY (ENGINE, J+  1)  IN  TRANSPORT . DAYS  DAYS 

486  ADD  1  TO  BASE.MISSILE.COUNTER< J+ 1> 

487  ELSE 

488  ADD  1  TO  J 

489  GO  CK 
418  ALWAYS 

411  LOOP 

412  END 


416  PROCESS  ENGINE. PRODUCT I ON 

417  DEFINE  RZ  AS  A  TEXT  VARIABLE 

418  DEFINE  I  ,J,K,NUMBER. OF. ENGINES. TO. PRODUCE  AS 
INTEGER  VARIABLES 

41?  DEFINE  DATE. TO. MAKE. ENGINE  AS  A  REAL  VARIABLE 

420  USE  15  FOR  INPUT 

421  READ  RZ 

422  FOR  I  «  1981  TO  1986 

423  DO 

424  READ  RZ 

425  FOR  J  -  1  TO  12 

426  DO 

427  READ  NUMBER. OF. ENGINES. TO. PRODUCE 

428  IF  NUMBER. OF. ENGINES. TO. PRODUCE  -  8  CYCLE  ALMAYS 

429  LET  DATE. TO. MAKE. ENGINE  - 

30/NUMBER .  OF .  ENGINES  .TO .  PRODUCE 

436  FOR  K  ■  1  TO  NUMBER. OF. ENGINES. TO. PRODUCE 

431  DO 

432  ACTIVATE  A  CREATE. ENGINE  IN  DATE.F<  J,  1 , 1)  ♦ 

DATE. TO. MAKE. ENGINE  DAYS 

433  ADD  30/NUMBER. OF. ENGINES. TO. PRODUCE  TO 
DATE  .TO  .MAKE .  ENGINE 

434  LOOP 

435  LOOP 

436  LOOP 

437  END 

438 

439 

440 

441  PROCESS  CREATE. ENGINE 

442  CREATE  AN  ENGINE 

443  LET  ENGINE.  I D.NUMBER< ENGINE)  -  ENGINE. SEQUENCE. NUMBER 

444  LET  TEST. STATUS< ENGINE)  -  NONE 

445  LET  TYPE < ENGINE)  *  101 

446  ADD  1  TO  ENGINE. SEQUENCE. NUMBER 

447  LET  TYPE. SERVICE* ENGINE)  -  LIMITED 

448  CALL  DATE< ENGINE) 

449  LET  LOCATION< ENGINE)  -  LOC. PRODUCTION 

450  FILE  THIS  ENGINE  IN  THE  PRODUCTION. POOL 

451  END 


455  ROUTINE  DATE (ENGINE) 

454  DEFINE  ENGINE  AS  AN  INTEGER  VARIABLE 

457  LET  START .  DATE  <  ENG  I NE)  -  INT.F(TIME.V) 

458  IF  RANDOM.  F(STREAM2)  <  FAIL. RATE 

457  LET  DATE.  EXP  I  RES  (ENGINE)  -  TIME.V  + 

RANDOM .  F <  STREAM3)  XTERM<TYPE<  ENGINE)  - 188) 

441  LET  TYPE. SERVICE( ENGINE)  -  REPAIR 

442  ACTIVATE  A  FAILURE.  ACT  I  ON<  ENGINE)  AT 
DATE .  EXPI  RES<  ENGINE) 

444  ELSE 

445  LET  DATE. EXPI RES( ENGINE)  -  TIME.V  ♦ 

TERM(TYPE<  ENGINE)  - 188) 

444  ACTIVATE  AN  OVERDUE.  ACT  ION  (ENGINE)  AT 
DATE. EXPI RES( ENGINE)  -  TRANSPORT . DAYS 
448  ALWAYS 

447  LET  RANK.  DATE  (ENGINE)  -  TERM(TYPE(  ENGINE)  -188)  ♦  TIME.V 
478  END 

473 

474  PROCESS  SCHEDULE. COtUERS I ON 

475  DEFINE  I,J  AS  INTEGER  VARIABLES 
474  DEFINE  R2  AS  A  TEXT  VARIABLE 

477  USE  17  FOR  INPUT 

478  READ  RZ 

477  FOR  I  -  1788  TO  1771 
488  DO  FOR  J  -  1  TO  12 

481  ACTIVATE  A  CONVERT  AT  DATE.F( J,  1 , 1) 

482  LOOP 

483  END 

484 

485 

484  PROCESS  CONVERT 

487  DEFINE  LI MI TED. QUOTA, FULL. QUOTA  AS  INTEGER  VARIABLES 

488  USE  17  FOR  INPUT 

487  READ  LI  MI  TED.  QUOTA,  FULL.  QUOTA 

478  ADD  LIMITED. QUOTA  TO  MAY. CONVERT (  1) 

471  ADD  FULL. QUOTA  TO  MAY. CONVERT (2) 

472  END 

473 

474  PROCESS  TRANSPORT (MSL) 

477  DEFINE  MSL  AS  AN  INTEGER  VARIABLE 

478  CALL  ADO. TO. SPARE. COUNT  GIVING  MSL 
477  IF  TYPE. SERVICE (MSL)  NE  LIMITED 

588  OR  TIME.V  <  DATE. F< OPEN. MO, OPEN. DAY, OPEN. YR) 

581  OR  N. X. WORK. STATI 0N(  1) /WILLIAMS. CAPACITY  < 

582  N.X. WORK. STATI CN( 2) /OCALC. CAPACITY 

583  SCHEDULE  A  MAINTENANCE (MSL, 1)  IN  TRANSPORT . DAYS  DAYS 

584  ELSE 

585  SCHEDULE  A  MAINTENANCE (MSL , 2)  IN  TRANSPORT . DAYS  DAYS 
584  ALWAYS 

587  CALL  SHIP  GIVING  MSL 

588  END 


912  PROCESS  TEST(MSL) 

513  DEFINE  MSL  AS  AN  INTEGER  MARI  ABLE 

514  LET  SHIPPING. STATUS(MSL)  -  NOME 

515  FILE  THIS  MSL  IN  THE  TEST. SET 
514  IF  TEST . STATUS (MSL)  -  EMIP 

517  WAIT  EMIP. TEST  DAYS 

518  ELSE 

519  WAIT  OTL.TEST  DAYS 
529  ALWAYS 

521  IF  MSL  IS  IN  TEST. SET 

522  REMOVE  THIS  MSL  FROM  TEST. SET 

523  IF  TEST. STATUS < MSL)  -  OTL  AND 

524  RANDOM.  F<  STREAM  1>  >-  RECOVERY.  FA  I  LURE.  RATE  OR 
TEST. STATUS < MSL)  »  EMIP 

525  LET  TYPE.SERVICE<MSL)  -  REFURB 

524  ACTIVATE  A  T»WSPORT<MSL)  NOW 

527  ELSE 

528  ADD  1  TO  DESTROYED 

529  ALWAYS 
539  ALWAYS 

531  END 

532 
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533  PROCESS  OVERDUE . ACT I ON (  ENG I NE> 

534  DEFINE  ENGINE  AS  AN  INTEGER  VARIABLE 

535  IF  DATE.  EXP  I  RES  (ENGINE)  NE  INT.F(TIME.V)  ♦TRANSPORT  .DAYS 
534  RETURN 

537  ALWAYS 

538  IF  CLAIM< ENGINE)  *  TAKEN 

539  WAIT  TRANSPORT .  DAYS  DAYS 
548  ALWAYS 

541  IF  ENGINE  IS  IN  ALERT. MISSILE. SET 

542  LET  STATUS( ENGINE)  *  DUE 

543  ADD  I  TO  NUM. OVERDUE 

544  CALL  ADD. TO. SPARE. COUNT  GIVING  ENGINE 

545  IF  N. TAKE. SET  -  8  AND  N. REPAIRED. SET<  1)  ♦ 

N. REPAIRED. SET < 2)  >  8 

544  ACTIVATE  AN  IN  .ACT I  ON( 8  .ENGINE)  NOW 

547  ELSE 

548  IF  ENGINE  IS  NOT  IN  TAKE. SET 

549  FILE  THIS  ENGINE  IN  THE  TAKE. SET 

558  AUAYS 

551  ACTIVATE  ttl  IN. ACTION  NOW 

552  ALWAYS 

553  ELSE 

554  IF  ENGINE  IS  IN  REPAIRED. SET 

555  CALL  REMOVE. FROM. REPAI RED. SET( ENGINE) 

554  ACTIVATE  A  MAINTENANCE  (ENGINE,  1)  NOW 

557  ELSE 

558  IF  ENGINE  IS  IN  PRODUCTION. POOL 

559  REMOVE  THIS  ENGINE  FROM  THE  PRODUCT  I  ON.  POOL 

548  CALL  SHIP  GIVING  ENGINE 

541  ACTIVATE  A  MAINTENANCE(  ENGINE ,  1)  IN 
TRANSPORT . DAYS  DAYS 

542  ELSE 

543  IF  SHI PPING.STATUS( ENGINE)  -  INTRANSIT 

544  LET  DATE.  EXP  I  RES  (ENGINE)  -  ARRIVAL  .TIME  (ENGINE)  ♦ 

545  1  ♦  TRANSPORT . DAYS 

544  ACTIVATE  AN  OVERDUE. ACTION( ENGINE)  AT 

ARRIVAL. TIME( ENGINE)  ♦  1 

547  ALWAYS 

548  ALWAYS 

549  ALWAYS 
578  ALWAYS 
571  END 


974  PROCESS  FA I LURE. ACT I  ON  (ENGINE) 

979  DEFINE  ENGINE  AS  AN  INTEGER  VARIABLE 
974  IF  DATE. EXP I RES (ENGINE)  NE  TIME.V 
977  RETURN 
979  AliAYS 

979  IF  CLAIM(ENGINE)  -  TAKEN 
9GG  WAIT  TRANSPORT .DAYS 
961  ALWAYS 

9G2  IF  ENGINE  IS  IN  ALERT. MISSILE. SET 

963  LET  STATUS (ENGINE)  -  BROKE 

964  ADD  1  TO  MUM. BROKEN 

969  CALL  ADD  .TO.  SPARE.  COUNT  GIVING  ENGINE 

964  REMOVE  THIS  ENGINE  FROM  THE  ALERT. MISSILE. SET 

967  IF  N .TAKE. SET  -  8  AND  N. REPAIRED. SET (  1)  ♦ 

N. REPAIRED. SET < 2)  >  8 

988  ACTIVATE  fit*  IN.  ACT  1 0N(  8 ,  ENGINE)  NOW 

989  ELSE 

998  IF  ENGINE  IS  NOT  IN  TAKE. SET 

991  FILE  THIS  ENGINE  IN  THE  TAKE. SET 

992  ALMAYS 

993  ACTIVATE  AN  IN.  ACT  I  ON  NOW 

994  ALWAYS 

999  ELSE 

994  IF  ENGINE  IS  IN  REPAIRED. SET 

997  CALL  REMOVE. FROM. REPAI RED. SET( ENGINE) 

998  ACTIVATE  A  MAINTENANCE(  ENGINE ,  1)  NOW 

488  ELSE 

481  IF  ENGINE  IS  IN  PRODUCT  I  ON.  POOL 

482  REMOVE  THIS  ENGINE  FROM  THE  PRODUCT  I  ON.  POOL 

483  CALL  SHIP  GIVING  ENGINE 

484  ACTIVATE  A  MAINTENANCE(  ENGINE ,  1>  IN 
TRANSPORT .  DAYS  DAYS 

489  ELSE 

484  IF  ENGINE  IS  IN  TEST. SET 

487  REMOVE  THIS  ENGINE  FROM  TEST. SET 

488  CALL  SHIP  GIVING  ENGINE 

489  ACTIVATE  A  MAINTENANCE( ENGINE,  1>  IN 
TRANSPORT .  DAYS  DAYS 

418  ELSE 

411  IF  SHI PPING.STATUS( ENGINE)  -  INTRANSIT 

412  LET  DATE. EXPIRES( ENGINE)  * 

ARRIVAL. TIME (ENGINE)  +  1  ♦  TRANSPORT . DAYS 
414  ACTIVATE  A  FA I LURE. ACT I ON (ENGINE)  AT 

ARRIVAL. TIME( ENGINE)  ♦ 1 

419  ALWAYS 

414  ALWAYS 

417  ALWAYS 

418  ALWAYS 

419  ALWAYS 
428  END 


624  PROCESS  IN  .ACTI  GN(MSL ,  FLAG) 

625  DEFINE  MSL, FLAG  AS  INTEGER  VARIABLES 

626  IF  FLAG  >  188 

627  GO  OUT 

628  ALtAYS 

629  FOR  EACH  ENGINE  OF  TAKE. SET  .WITH  CLAIM< ENGINE)  NE  TAKEN, 

638  FIND  FLAG-  ENGINE, 

631  IF  FOUND 

632  GO  OUT 

633  ALWAYS 

634  IF  EARLY. OVERHAUL. OK  -  YES 

639  FOR  EACH  ENGINE  OF  ALERT. MISSILE. SET,  WITH 
CLAIMC ENGINE)  NE  TAKEN  AND  STATUS< ENGINE)  *  NONE, 

FIND  FLAG  -  ENGINE, 

IF  FOUNO 
637  GO  OUT 

63G  ALWAYS 
639  ALWAYS 

648  IF  MSL  NE  8 

641  IF  MSL  IS  NOT  IN  REPAIRED. SET 

642  FILE  THIS  MSL  IN  REPAIRED. SET(  1) 

643  ALWAYS 

644  ALWAYS 

649  RETURN 

646  'OUT' 

647  IF  MSL  >  188 

648  GO  OUT 1 

649  ALWAYS 

698  IF  N. REPAIRED. SET < 1)  IS  >-  N. REPAIRED. SET (2) 

691  AND  REPAIRED. SET( 1)  IS  NOT  EMPTY 

692  REMOVE  FIRST  MSL  FROM  REPAIRED. SET <  1) 

693  ELSE 

694  IF  REPAIRED. SET (2)  IS  NOT  EMPTY 

699  REMOVE  FIRST  MSL  FROM  REPAIRED. SET (2) 

696  ELSE 

697  IF  FLAG  NOT  IN  TAKE. SET  AND  STATUS< FLAG)  NE  NONE 

698  FILE  THIS  FLAG  IN  TAKE. SET 

699  ALWAYS 

668  RETURN 

661  ALWAYS 

662  ALWAYS 

663  'OUT1 ' 

664  CALL  SHIP  GIVING  MSL 

669  LET  CLA1M<FLAG)  -  TAKEN 

666  ACTIVATE  AN  ENTER.  BASE  (MSL,  FLAG)  IN  TRANSPORT .  DAYS  DAYS 

667  END 


671  PROCESS  ENTER. BASE(ENGINE. IN, FLA0> 

672  DEFINE  ENGINE. IN, ENGINE. OUT, FLAG  AS  INTEGER  VARIABLES 

673  LET  SHI PPING.STATUS< ENGINE. IN>  -  NONE 

674  IF  N. TAKE. SET  -  0 

679  LET  ENGINE. OUT  *  FLAG 

676  LET  CLAIM< ENGINE. OUT>  *  NONE 

677  GO  START 

678  ALWAYS 

679  LET  CLAIM<FLAG>  «  NONE 

6G0  IF  FLAG  IS  NOT  IN  TAKE. SET  t*4D  STATUS< FLAG)  NE  NONE 

681  FILE  THIS  FLAG  IN  TAKE. SET 

682  ALWAYS 

683  FOR  EACH  ENGINE  OF  TAKE.  SET,  WITH  LOCATION  (ENGINE)  - 
LOCATION  (FLAG)  AND  CLAIM<  ENGINE)  NE  TAKEN, 

FIND  ENGINE. OUT  *  ENGINE, 

689  IF  FOUND 

686  GO  START 

687  ALMAYS 

688  LET  ENGINE. OUT  -  FLAG 

689  '  START ' 

690  IF  TEST.  STATUS<  ENGINE.  OUT)  -  EVIP  AND  STATUS  (ENGINE.  OUT) 
NE  BROKE 

691  CALL  SHIP  GIVING  ENGINE. OUT 

692  ACTIVATE  A  TEST  (ENGINE.  OUT)  IN  TOWSPORT.DAYS  DAYS 

693  ELSE 

694  ACTIVATE  A  TRANSPORT  (ENGINE.  OUT)  NOW 
699  ALMAYS 

696  IF  STATUS( ENGINE. OUT)  *  DUE 

697  SUBTRACT  1  FROM  NUM. OVERDUE 

698  ELSE 

699  IF  STATUS( ENGINE. OUT)  »  BROKE 

700  SUBTRACT  1  FROM  NUM. BROKEN 

70 1  ALMAYS 

702  ALWAYS 

703  'SWAP' 

704  IF  ENGINE. OUT  IS  IN  TAKE. SET 

709  REMOVE  THIS  ENGINE. OUT  FROM  TAKE. SET 

706  ALMAYS 

707  IF  M. ALERT .Ml SSI LE.SET( ENGINE. OUT)  NE  0 

708  REMOVE  THIS  ENGINE. OUT  FROM  ALERT. MISSILE. SET 
799  ALMAYS 

710  LET  STATUS( ENGINE. OUT)  -  NONE 

711  LET  LOCATION(  ENGINE.  IN)  -  LOCATION  (ENGINE.  OUT) 

713  FILE  THIS  ENGINE. IN  IN  THE  ALERT. MISSILE. SET 
719  END 


71?  PROCESS  DEPOT  1. CAPACITY. SCHEDULE 

729  DEFINE  MONTH, DAY, YEAR, CAPACITY, OLD  AS  INTEGER  VARIABLES 

721  LET  OLD  -  299 

722  7 START' 

723  USE  1?  FOR  INPUT 

724  IF  DATA  IS  NOT  ENDED 

725  READ  CAPACITY, MONTH, DAY, YEAR 

726  IF  OATE.F<MONTH, DAY, YEAR)  >-  TIME.V 

727  WAIT  DATE. F(MONTH, DAY, YEAR)  -  TIME.V  DAYS 

728  RELINQUISH  (299-OLD)  UNITS  OF  WORK. STATICN< 1) 

729  REQUEST  <29 9 -CAPACITY)  UNITS  OF  WORK . STATI ON<  1) 

WITH  PRIORITY  1 

739  LET  OLD  -  CAPACITY 

731  ALWAYS 

732  GO  TO  START 

733  ALWAYS 

734  END 

735 

736 

737 

738  PROCESS  DEP0T2. CAPACITY. SCHEDULE 

73?  DEFINE  MONTH, DAY, YEAR, CAPACITY, OLD  AS  INTEGER  VARIABLES 
749  LET  OLD  -  299 

741  7  CTADT' 

742  USE  21  FOR  INPUT 

743  IF  DATA  IS  NOT  ENDED 

744  READ  CAPACITY, MONTH, DAY, YEAR 

743  IF  DATE. F(MONTH, DAY, YEAR)  >«  TIME.V 

746  WAIT  DATE. F (MONTH, DAY, YEAR)  -  TIME.V  DAYS 

747  RELINQUISH  (299-OLD)  UNITS  OF  WORK. STATI ON (2) 

748  REQUEST  (299-CAPACITY)  UNITS  OF  WORK.  STATI  ON  <  2) 

WITH  PRIORITY  1 

74?  LET  OLD  -  CAPACITY 

739  ALWAYS 

731  GO  TO  START 

732  ALWAYS 

733  END 


7^7  ppnrP^Q  uai  t 

758  DEFINE  I  ,B2,02  AS  INTEGER  VARIABLES 
75?  START  NEM  PAGE 

760  PRINT  2  LINES  WITH  LIFE. MAX  THUS 

761  THE  MAXIMUM  NUMBER  OF  SPARE  ENGINES  REQUIRED  OVER  THE 

762  LIFE  OF  THE  SYSTEM  IS  XXXX 

763  START  NEM  PAGE 

764  FOR  I  -  8  TO  END.YR  -  START. YR 

765  DO 

766  IF  FRAC.F< I/5>  -  8.  START  NEM  PAGE  ALWAYS 

767  PRINT  1  LINE  MITH  d  +  START  .YR)  THUS 

768 

XXXXJAN  FEB  MAR  APR  MAY  JUN  JUL  AUG  SEP  OCT  NOV  DEC 

769  PRINT  1  LINE  MITH  SPARES< IX 12* 1 , I) , SPARES < IX 12*2, t> , 

770  SPARES< IX 12+3, 1) ,  SPARESdX  12+4, 1) , 

771  SPARES< 1X12+5, 1> .SPARESdX  12+6, 1) , 

772  SPARESdX  12+7, 1) ,SPARES< IX 12+G, 1> , 

773  SPARES< I X 12+9 , 1> ,SPARES(IX12+10, 1> , 

774  SPARESdX  12+  11,1)  ,SPARES<  1X12+ 12, 1> 

THUS 

775 

INC  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

776  PRINT  1  LINE  MITH  SPARES < IX 12+ 1 ,2> ,SPARES< IX 12+2, 2> , 

777  SPARES< IX 12+3, 2>  , SPARESdX  12+4,2)  , 

77S  SPARESdX  12+5,2)  , SPARESdX  12+6,2)  , 

779  SPARESdX  12+7,2)  , SPARESdX  12+8,2)  , 

780  SPARES< IX  12+9,2)  , SPARESdX  12+ 10 ,2)  , 

781  SPARES(IX12+11,2)  , SPARESdX  12+ 12, 2> 

THUS 

782  TOT.REQ 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

783  PRINT  1  LINE  MITH 

AVERAGE. AGE< IX  12+  1, 1)  , AVERAGE. AGEdX  12+2, 1)  , 

784  AVERAGE.  AGE  (IX  12+3, 1)  ,  AVERAGE  .AGEdX  12+4, 1)  , 

785  AVERAGE. AGEdX  12+5,  1)  , AVERAGE. AGEdX  12+6, 1)  , 

786  AVERAGE.  AGEdX  12+7,  1)  ,  AVERAGE  .AGEdX  12+8,  1)  , 

787  AVERAGE. AGEdX  12+9, 1)  , AVERAGE. AGE (IX  12+  10 , 1)  , 

788  AVERAGE. AGEdX  12+ 1 1, 1)  ,AVERA6E.AGE(IX  12+ 12, 1) 
THUS 

789  AGE 101 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

790  PRINT  1  LINE  WITH 

AVERAGE . AGE( I X 12+ 1,2) , AVERAGE. AGE( IX 12+2,2) , 

791  AVERAGE. AGE( IX 12+3,2) , AVERAGE. AGE (IX 12+4,2) , 

792  AVERAGE. AGE(  IX  12+5,2)  , AVERAGE. AGEdX  12+6,2)  , 

793  AVERAGE. AGE(  IX  12+7,2)  , AVERAGE. AGEdX  12+8,2)  , 

794  AVERAGE. AGEdX  12+9,2)  , AVERAGE. AGEdX  12+  10 ,2)  , 

795  AVERAGE. AGEdX  12+ 11, 2)  , AVERAGE. AGEdX  12+  12,2) 
THUS 


796  AGE 104 
XXX  XXX 


XXX  XXX  XXX  XXX  XXX  XXX 


XXX  XXX 


/  / 


PROCESS  HALT  CONTINUED 
797  PRINT  1  LINE  WITH 

MAINTENANCE . RECORD < I X 12+ 1 , 1) , 

MAINTENANCE. RECORD ( IX 12+2, 1) , 

799  MAINTENANCE. RECORD < IX 12+3, 1> , 

MAINTENANCE . RECORD < IX 12+4, 1)  , 

808  MAINTENANCE . RECORD < 1X12+9,1), 

MAINTENANCE. RECORD ( IX 12+6, 1)  , 

801  MAINTENANCE.REC0RD(IX12+7, 1) , 

MAINTENANCE . RECORD < 1X12+8,1), 

802  MAINTENANCE . RECORD ( 1X12+9,1), 

MAINTENANCE . RECORD < 1X12+10,1), 

803  MAINTENANCE . RECORD< I X 12+ 11,1), 

MAINTENANCE. RECORD < IX 12+ 12, 1)  THUS 

804  MINORS 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

805  PRINT  1  LINE  WITH 

MAINTENANCE. RECORD ( IX 12+ 1,2) , 

806  MAINTENANCE. RECORD< IX 12+2,2) , 

807  MAINTENANCE. RECORD< IX 12+3,2) , 

MAINTENANCE. RECORD ( I X 12+4,2) , 

808  MAINTENANCE. RECORD< IX 12+5,2) , 

MAINTENANCE. RECORD< IX 12+6,2) , 

809  MAI NTENANCE.RECORD< IX 12+7,2) , 

MAINTENANCE. RECORD ( IX 12+8,2) , 

810  MAI NTENANCE.RECORD< IX 12+9,2)  , 

MAINTENANCE. RECORD< IX 12+ 10, 2) , 

811  MAINTENANCE .  RECORD<  1X12+11,2)  , 

MAINTENANCE. RECORD< IX 12+ 12,2)  THUS 

812  MAJORS 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

813  PRINT  1  LINE  WITH 

MAINTENANCE . RECORD ( 1X12+1,3), 

8 14  MAINTENANCE . RECORD ( I X 12+2 , 3)  , 

815  MAINTENANCE. RECORD< IX 12+3,3) , 

MAINTENANCE. RECORD ( IX 12+4,3) , 

816  MAINTENANCE.RECORD( IX 12+5,3) , 

MAINTENANCE. RECORD ( IX 12+6,3)  , 

817  MAINTENANCE. RECORD( IX 12+7,3) , 

MAINTENANCE. RECORD ( 1X12+8,3)  , 

818  MAINTENANCE. RECORD< IX 12+9,3) , 

MAINTENANCE. RECORD < IX 12+ 10 ,3)  , 

819  MAINTENANCE. RECORD ( IX 12+ 11,3) , 

MAINTENANCE .RECORD ( 1X12+12,3)  THUS 

820  UNSCHD 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 


"  PROCESS  HALT  CONTINUED 

821  PRINT  1  LINE  MITH 

MAINTENANCE . RECORD < 1*12+1,4) , 

822  MAINTENANCE. RECORD<  IX  12+2,4)  , 

823  MAI NTENANCE. RECORD( IX 12+3,4) , 

MAINTENANCE. RECORD < 1X12+4,4) , 

824  MAI NTENANCE.RECORD(  IX  12+3,4)  , 

MAINTENANCE. RECORD < IX 12+6,4) , 

823  MAINTENANCE . RECORD < 1X12+7,4), 

MAINTENANCE. RECORD ( 1X12+8,4) , 

826  MAINTENANCE . RECORD < 1X12+9,4), 

MAINTENANCE . RECORD< 1 X 12+ 10 , 4) , 

827  MAINTENANCE . RECORD < 1X12+11,4), 

MAINTENANCE. RECORD < IX 12+ 12,4)  THUS 

828  REPURB 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

829  PRINT  2  LINES  WITH 

MAI NTENANCE. RECORD (  IX  12+  1,5)  , 

830  MAINTENANCE . RECORD ( 1X12+2,3), 

831  MA I NTENANCE. RECORD< IX 12+3,5) , 

MAI NTENANCE. RECORD ( IX 12+4,5) , 

832  MAINTENANCE.R£CORD<  IX  12+5,3)  , 

MAINTENANCE . RECORD < I X 12+6 , 5) , 

833  MAINTENANCE. RECORD< IX 12+7,5) , 

MA I NTENANCE. RECORD< IX 12+8,5) , 

834  MAINTENANCE. RECORD<  IX  12+9,5)  , 

MAI NTENANCE. RECORD < IX 12+ 10 ,5) , 

835  MAINTENANCE . RECORD ( 1X12+11,3), 

MAI NTENANCE. RECORD ( IX 12+ 12,5)  THUS 

836  CONNER 

XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX  XXX 

837 

838  LOOP 

839  LET  B2  »  TRUNC . F <  BROKENUM/2) 

LET  02  *  TRUNC .  F<  OVERNUM/2) 

840  PRINT  3  LINES  WITH  B2 , BR0KESUM/B2 , BROKESUM  THUS 

841  XXXXXX  MISSILES  MERE  BROKEN  AT  DEPLOYMENT  BASES  THROUGH- 

842  OUT  THE  LIFE  OF  THE  SYSTEM.  THEY  AVERAGED  XXX. XX  DAYS 

843  ON  BASE  < BROKEN)  BEFORE  BEING  REPLACED  FOR  A  TOTAL  OF 
XXXXXX. XX  DAYS  IN  INOPERABLE  STATUS. 

844 

845 

846  PRINT  4  LINES  WITH  02,  0VERSUM/02  -  TRANSPORT . DAYS , 

847  OVERSUM  -  02  X  TRANSPORT . DAYS  THUS 

848  XXXXX  MISSILES  WERE  KEPT  IN  A  DEPLOYED  STATUS  PAST 

849  THEIR  WARRANTED  LIFE  THROUGHOUT  THE  LIFE  OF  THE  SYSTEM. 

850  THEY  AVERAGED  XXX. XX  DAYS  ON  BASE  (OVERDUE)  BEFORE 

851  BEING  REPLACED  FOR  A  TOTAL  OF  XXXXXX. XX  DAYS  OVERDUE. 

852  STOP 

853  END 

854 

855 


111 


85 6  PROCESS  MONTHLY. STATIST ICS 

837  DEFINE  LAST  1  AS  A  SAVED  INTEGER  VARIABLE 

838  DEFINE  DIVISOR. 1 , DIVISOR. 4  AS  INTEGER  VARIABLES 

839  DEFINE  TOTAL. 1,  TOTAL. 4  AS  REAL  VARIABLES 
868  ADD  1  TO  COUNT 

861  LET  DIVISOR. 1  *  8  LET  DIVISOR. 4  -  8 

862  LET  TOTAL. 1  -  8  LET  TOTAL. 4  -  8 

863  FOR  EACH  ENGINE  OF  ALERT. MISSILE. SET 

864  DO 

863  IF  TYPE  (ENGINE)  -  181 

866  ADD  1  TO  DIVISOR. 1 

867  ADD  TIME. V-START.DATE< ENGINE)  TO  TOTAL. 1 

868  ELSE  "  184 

869  ADD  1  TO  DIVISOR. 4 

878  ADD  TIME.V  -  START. DATE< ENGINE)  TO  TOTAL. 4 

871  ALWAYS 

872  LOOP 

873  IF  DIVISOR. 1  -  8  LET  DIVISOR. 1  ■  1  ALWAYS 

874  IF  DIVISOR. 4  *  8  LET  DIVISOR. 4  -  1  ALWAYS 

875  LET  AVERAGE. AGE (COUNT , 1)  -  TRUNC. F( TOTAL. 1/DIVISOR. 1) 

876  LET  AVERAGE . AGE( COUNT , 2)  -  TRUNC. F(TOTAL. 4/DIVISOR. 4) 

877  LET  SPARES( COUNT 1 2)  -  MAX. PER. MONTH 

878  IF  LIFE. MAX  -  LAST 1  >  8 

879  LET  SPARES(COUNT ,  1)  -  LIFE.r-WX  -  LAST  1 
888  LET  LAST 1  -  LIFE. MAX 

88 1  AU*WYS 

882  RESET  MONTHLY  TOTALS  OF  NUM. SPARE 

883  END 

884 

885 

886  ROUTINE  SHIP(MSL) 

887  LET  ARRIVAL .TIME(MSL)  -  TRUNC. F(TIME.V)  +  TRANSPORT . DAYS 

888  LET  SHI  PP . STATUS(MSL)  -  INTRANSIT 

889  RETURN 
898  END 

891 

892 

893  PROCESS  DEPLOY ( MSL , BASE) 

894  DEFINE  MSL, BASE  AS  INTEGER  VARIABLES 
893  LET  LOCATI GN(MSL)  *  BASE  +  2 

896  LET  SHI PPING . STATUS(MSL)  *  NONE 

897  FILE  THIS  MSL  IN  THE  ALERT. MISSILE. SET 

898  END 

899 
988 

981 

982  ROUTINE  ADD. TO. SPARE .COUNT (MSL) 

983  IF  SPARE. STATUS (MSL)  NE  SPARE 

984  ADD  1  TO  NUM. SPARE 

983  LET  SPARE. STATUS (MSL)  *  SPARE 

986  ALWAYS 

987  RETURN 

988  END 
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911  ROUTINE  SUBTRACT . FROM . SPARE . COUNT < MSL) 

912  IF  SPARE. STATUS(MSL)  *  SPARE 

913  SUBTRACT  1  FROM  NUM.  SPARE 

914  LET  SPARE. STATUS(MSL)  -  NONE 

915  ALMAYS 

916  RETURN 

917  END 

918 

919 

920 

921  ROUTINE  REMOVE. FROM. REPAIRED. SET <MSL> 

922  DEFINE  MSLf  ENGINE  AS  INTEGER  VARIABLES 

923  FOR  EACH  ENGINE  OF  REPAIRED. SET< 1) , 

924  NITH  ENGINE. ID. NUMBER (ENGINE)  -  ENGINE. ID .NUMBER (MSL) 

925  FIND  THE  FIRST  CASE, 

IF  FOUND 

926  REMOVE  THIS  ENGINE  FROM  REPAIRED. SET< 1> 

927  RETURN 

928  ALMAYS 

929  FOR  EACH  ENGINE  OF  REPAIRED. SET (2) , 

930  HITH  ENGINE.  I D.  NUMBER  (  ENGINE)  =*  ENGINE.  ID.  NUMBER  (MSL) 

931  FIND  THE  FIRST  CASE, 

IF  FOUND 

932  REMOVE  THIS  ENGINE  FROM  REPAIRED. SET (2) 

933  RETURN 

934  ALMAYS 

935  END 


END  OF  PROGRAM  LISTING 


Appendix  F:  Expl anation  of  Program  Term* 


Refer  to  APPENDIX  Es  Program  Listing  -for  the  context  in 
which  the  following  terms  are  used.  Hords  appearing  in  all 
CAPITALS  are  names  used  in  the  program. 


Arrays 


AVERAGE. AGE  -  Stores  the  average  age  o-f  all  engines  on  alert 
by  type,  101  or  104. 

MAINTENANCE. RECORD  -  Stores  the  number  o-f  each  type  o-f  depot 
service  (FULL,  LIMITED,  etc.)  accomplished  at  each  depot. 

MAY. CONCERT  -  The  cumulative  number  o-f  conversions  scheduled 
per  month  -for  both  limited  and  -full  service  overhauls. 

SPARES  -  Stores  the  maximum  number  o-f  spare  engines  required 
by  the  system  -for  each  month. 

TERM  -  Stores  the  length  o-f  warranty  for  each  type  of 
engine. 

WORK. STATIONS. IN. USE  *  Stores  the  total  number  of 

MORK. STATIONS  in  use  at  each  depot  at  any  given  time. 


Attributes  of  Each  Engine 


ARRIVAL. TIME  -  The  date  an  engine  should  arrive  at  the  next 
process  after  being  shipped. 

CLAIM  -  Identifies  an  engine  as  being  previously  selected 
for  a  process,  such  as  a  test  or  exchange. 

DATE. EXPIRES  -  The  end  of  an  engine's  warranted  lifetime  or 
date  of  random  failure. 

ENGINE. ID. NUMBER  -  A  unique  identification  for  each  engine. 

LOCATION  -  Indicates  where  the  engine  ist  at  a  base,  depot, 
production,  etc. 

RANK. DATE  -  Date  used  to  establish  an  engine's  priority  over 
other  engines  for  selection  for  testing  or  early  overhaul. 


SHIPPING. STATUS  -  Indicate*  if  the  engine  is  INTRANSIT 
< being  shipped  from  one  location  to  another)  or  not. 


START. DATE  -  Date  engine's  current  warranted  period  begins. 


SPARE. STATUS  -  Indicates  if  an  engine  is  being  used  as  a 
spare  engine  (while  it  is  being  processed  in  MAINTENANCE, 
TEST,  TRANSPORT,  etc). 


STATUS  -  Shows  if  an  engine  is  serviceable  (NONE),  requires 
servicing  (DUE),  or  has  failed  (BROKE). 


TEST. STATUS  -  Indicates  the  type  of  test  an  engine  will 
undergo  (NONE  if  not  selected  for  testing). 


TYPE  -  Indicates  what  model  the  engine  is,  F107-101  (101)  or 
F 107- 104  (104). 


TYPE. SERVICE  -  Shows  what  type  of  servicing  is  required 
next:  FULL  overhaul,  LIMITED  overhaul,  REFURBi shmen t  after  a 
test,  REPAIR  due  to  a  failure,  or  CONVERSION  if  an  engine 
will  be  converted  from  a  101  to  a  104. 


EoUtiti 


BASE  -  Six  bases  are  in  the  original  design  with  attributes 
of  BASE .MISSILE. COUNTER  and  BASE .MI SSI LE . RQMT .  These  at¬ 
tributes  are  used  to  record  the  number  of  missiles  actually 
at  each  base  and  the  number  required  for  each  base. 

DEPOT  -  Two  depots,  each  with  their  own  pool  of  repaired, 
serviceable  engines  called  a  REPAIRED. SET. 


EC.9Sff.ttl 


CONVERT  -  Reads  input  values  from  an  external  file  (SIMU17) 
which  are  the  quota  of  engines  the  system  MAY. CONVERT  each 
month  during  the  conversion  period. 


CREATE. ENGINE  -  Creates  new  entities  (engines)  and  assigns 
values  to  their  attributes.  Places  the  engines  in  the 
PRODUCTION. POOL. 


DEPLOY  -  Updates  an  incoming  missile's  location  to  the  cor¬ 
rect  base  and  places  it  in  that  base's  ALERT. MISSILE. SET. 


Activated  for  a  missile's  initial  deployment  and  for  return- 


REFURBished  OTL  test  missile  to  its  correct  base. 


:jvy.y; 


DEPOT 1. CAPACITY. SCHEDULE,  DEP0T2. CAPACITY. SCHEDULE  -  Gives 
the  program  operator  the  capability  to  vary  the  number  o f 
MORK. STATIONS  available  at  each  depot.  The  number  of  sta¬ 
tions  can  be  adjusted  on  any  date  desired  by  reading  the 
date  and  amount  of  capability  from  input  files  (3IMU1?  and 
S1MU21)  . 

ENGINE.  PRODUCT  I  ON  -  Reads  the  NUMBER.  OF.  ENGINES  .TO.  PRODUCE 
from  an  input  file  <SIMU19>  and  activates  the  process 
CREATE. ENGINE  to  produce  the  designated  number  each  month. 

ENTER. BASE  -  Controls  the  entry  and  exit  of  engines  to  and 
from  the  base.  Verifies  the  priority  of  selections  made  by 
IN. ACTION  by  reviewing  the  TAKE. SET.  Activates  processes 
depending  on  whether  the  outgoing  engine  is  scheduled  for  a 
TEST  or  MAINTENANCE.  Updates  the  number  of  engines  broken 
or  overdue  as  needed.  Ramoves  the  outbound  engine  from  base 
sets.  Assigns  the  old  engine's  base  location  to  the  new 
engine  and  places  the  new  engine  in  the  ALERT .MISSILE. SET. 

FAILURE .ACTION  -  Activated  by  the  DATE  routine.  Processes 
engines  which  have  failed.  Reviews  the  ALERT .MISSILE. SET, 
TAKE. SET,  or  PRODUCT I ON. POOL  as  required  to  remove  the 
failed  engine  from  the  set  and  schedules  an  IN. ACTION  or 
MAINTENANCE  as  appropriate.  Updates  the  engine's  attributes 
to  reflect  this  processing.  It  also  changes  system  vari¬ 
ables,  such  as  NUM. BROKEN,  to  reflect  a  failure. 

HALT  -  Prints  the  final  report  of  the  system's  performance. 
Lists  the  spares  used  and  each  type  of  maintenance  performed 
by  year  and  month.  Reports  on  the  number  of  missiles  broken 
in  the  simulation  and  the  time  it  took  to  replace  them. 
Reports  the  number  and  average  time  on  alert,  past  the  war¬ 
ranted  time,  for  overdue  engines. 

IN. ACTION  -  Activated  by  a  need  for  an  engine  or  the  availa¬ 
bility  of  one.  Tries  to  match  a  need  with  an  available 
spare  engine.  Searches  the  TAKE. SET  to  see  if  it  contains 
an  engine  needing  to  be  changed  out.  If  an  engine  at  the 
base  needs  to  be  exchanged  the  REPAIRED. SETs  are  checked  for 
the  availability  of  spares.  ENTER. BASE  is  activated  if  a 
match  is  found. 

MAIN  -  Initiates  program  activity.  Reads  initial  values  for 
variables  from  input  files  SIMU7  and  SIMU9.  Dimensions  the 
arrays  and  provides  the  appropriate  number  of  DEPOTS,  BASEs, 
and  WORK. STATIONS.  Schedules  the  processes  that  begin  the 
simul at ion . 

MAINTENANCE  -  Records  the  TYPE. SERVICE  in  the 
MA I NTENANCE. RECORD.  Determines  if  the  engine  should  be  con¬ 
verted  and  if  the  conversion  service  is  available.  Uses  a 
WORK. STATION  for  the  required  amount  of  time  and  updates  the 
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TYPE. SERVICE  due  -for  its  next  servicing.  Releases  the 
MORK. STATION  and  updates  th#  •ngin#/s  dates  and 
SPARE. STATUS.  Notifies  th#  SYSTEM  of  a  spar#  #ngin#  availa¬ 
bility  and  sch#du1#s  #xchang#  proc#ss#s  as  appropriate,  or 
places  th#  repaired  engine  in  the  depot  stock. 

MISSILE. PRODUCTION  -  Reads  the  missile  production  schedule 
from  an  input  file  (SIMU13) .  Schedules  a  SHIP. MISSILE  to 
send  the  missiles  to  each  base. 

MONTHLY . STATI STI CS  -  Computes  and  records  the  AVERAGE .AGE  of 
the  16!  and  104  type  engines  and  various  other  system 
statistics.  Records  the  number  of  SPARES  used  for  the  month 
and  the  total  used  for  the  life  of  the  system. 

OVERDUE.  ACTION  -  Removes  the  engine  from  ALERT  .MISSILE.  SET, 
REPAIRED. SET,  or  PRODUCT I  ON. POOL.  Records  the  STATUS  as  DUE 
and  schedules  an  IN.ACTION  or  MAINTENANCE  as  needed. 

SCHEDULE. CONVERSION  -  Activates  CONVERT  processes  each  month 
during  the  conversion  period. 

SHIP. MISSILE  -  Selects  engines  for  shipment  from  the 
PRODUCT I ON. POOL.  Schedules  the  process  DEPLOY  until  the 
BASE. MISSILE. COUNTER  quantity  for  each  base  matches  that 
base's  BASE.MISSILE.RGMT . 

SPARE. ENGINE. GENERATION  -  Produces  the  spare  engines  for  the 
system  and  assigns  initial  values  to  their  attributes. 
"Creates*  engines  at  the  rate  of  five  per  month  until  the 
NUMBER. SPARES  to  be  created  is  reached.  Places  the  engines 
in  the  REPAIRED. SET  for  depot  1  unless  an  immediate  need  is 
found,  in  which  case  the  process  IN.ACTION  is  activated  to 
satisfy  that  need. 

TEST  -  Places  the  engine  in  the  TEST. SET  while  the  test  is 
in  progress.  The  length  of  time  in  the  TEST. SET  depends  on 
the  type  of  test  performed.  After  testing,  the  TYPE. SERVICE 
is  set  to  REFURB  with  the  exception  of  unrecovered  OTL 
missiles,  which  are  simply  destroyed. 

TEST. GENERATION  -  Reads  the  type  and  date  of  each  test  from 
an  input  file  <SIMU11>  and  schedules  the  process  TEST. PICK 
as  required. 

TEST. PICK  -  Selects,  for  each  test,  the  engine  from  the 
ALERT .MISSILE. SET  which  is  furthest  past  its  warranty  expi¬ 
ration  date,  or  if  none  is  past,  the  engine  closest  to  its 
warranty  expiration  date.  Engines  picked  for  EVIP  tests  are 
processed  through  IN.ACTION  to  locate  a  spare  engine  to  take 
their  place  at  the  base.  The  engine's  STATUS  and 
SPARE. STATUS  are  updated  as  needed.  Missiles  picked  for  OTL 
tests  are  scheduled  for  a  TEST  at  this  time. 


TRANSPORT  -  Update*  the  SPARE .  STATUS ,  then  schedules  th« 
engine  -for  MAINTENANCE  at  the  appropriate  depot. 


Routines 


ADO . TO . SPARE . COUNT  -  Records  an  increase  in  the  number  o-f 
spares  needed  (NUM. SPARES)  and  updates  the  SPARE. STATU8 
attribute  o-f  the  engine. 


DATE  -  Assigns  a  START. DATE,  a  DATE. EXPIRES,  and  a  RANK. DATE 
to  each  engine.  Schedules  a  FA  I  LURE.  ACT  I  ON  or  an 
OVERDUE. ACTION  on  the  basis  o-f  a  random  number  generated  by 
the  system.  I-f  this  number  is  less  than  the  FAIL. RATE,  the 
engine  Mill  fail  early.  For  a  failed  engine,  the 
DATE. EXPIRES  is  a  random  percentage  of  the  warranted 
lifetime. 


REMOVE. FROM. REPAIRED. SET  -  Locates  the  desired  engine  in  the 
REPAIRED. SET  at  one  of  the  depots  and  removes  it. 


SUBTRACT . FROM . SPARE . COUNT  -  Records  a  decrease  in  the  number 
of  spares  needed  <NUM. SPARES)  and  updates  the  SPARE. STATUS 
attribute  of  the  engine. 


ALERT, MISSILE. SET  -  Contains  missiles  which  are  in  opera¬ 
tional  use  at  a  base. 


PRODUCTION. POOL  -  Missiles  are  stored  in  this  set  until 
deployed  to  a  base. 


TAKE. SET  -  Maintains,  in  priority  order,  those  engines  which 
need  to  be  exchanged  but  can't  because  a  spare  is  not  im¬ 
mediately  available. 


TEST. SET  -  Keeps  track  of  engines  during  testing. 


VtrUbTn 


COWERT.DAY,  CONVERT  .MO,  COWERT.YR 
conversions  begin. 


-  The  date  181  to  184 


CONVERSION. TIME,  FULL-TIME,  LIMITED. TIME,  REFURB.TIME  -  The 
amount  of  time  required  to  complete  depot  maintenance  for 
•ach  typo  of  service. 

COUNT  -  A  countor  used  as  a  subscript  in  various  arrays  to 
indicat#  which  month  of  th#  simulation  is  being  rocordod. 

DAY. CONVERSIONS. END,  MO. CONVERSIONS. END,  YR. CONVERSIONS. END 
-  Th#  dat#  at  which  conversions  < under  ideal  conditions) 
should  b#  finished. 

DESTROYED  -  Records  the  number  of  engines  destroyed  due  to 
testing. 

EARLY. OVERHAUL. OK  -  A  capability  to  allow  engines  which  have 
not  completed  their  warranted  time  on  base  to  be  serviced 
early.  This  could  result  in  smoother  depot  work  loads. 
This  capability  is  not  used  in  the  initial  simulation. 

END.  DAY,  END  .MO,  END.YR  -  The  ending  date  of  the  simulation. 

ENGINE. SEQUENCE. NUMBER  -  Maintains  the  ENGINE. ID. NUMBER  of 
the  last  engine  produced.  Used  to  sequence  the 
ENGINE. ID. NUMBERS  as  engines  are  produced. 

EVIP.TEST,  OTL.TEST  -  The  length  of  time  required  for  EVIP 
and  OTL  testing. 

FAIL. RATE  -  Percentage  of  engines  which  will  fail  at  some 
point  in  their  warranted  lifetime. 

FULL. TIME  -  See  CONVERSION. TIME. 

LIMITED. TIME  -  See  CONVERSION. TIME. 

MONTH. CONVERSIONS. END  -  See  DAY. CONVERSIONS. END 

NUMBER. BASES  -  The  number  of  bases  where  ALCMs  are  deployed 
in  the  simulation. 

NUMBER . SPARES  -  The  number  of  spare  engines  provided  to 
support  the  systsm. 

NUM. BROKEN,  NUM. OVERDUE,  NUM. SPARE  -  Stores  the  number  of 
engines  that  are  currently  broken,  overdue,  or  being  used  as 
or  requiring  a  spare. 

OCALC. CAPACITY,  WILLIAMS. CAPACITY  -  The  number  of  work  sta¬ 
tions  established  at  the  depots.  This  is  the  number  of 
engines  that  can  be  serviced  by  the  depot  at  the  same  time. 

OPEN. DAY,  OPEN. MO,  OPEN.YR  -  The  date  Oklahoma  City  ALC 
(OCALC)  begins  depot  operations. 


(JTL.TEST  -  See  EV IP. TEST 

RECOVERY. FAILURE. RATE  -  Percentage  of  OTL  test  launches 
which  are  not  recovered. 

REFURB.TIME  -  See  COWERS  I  ON.  TIME 

START. DATE  -  The  date  at  which  an  engine  begins  its  war¬ 
ranted  lifetime. 

START. DAY,  START. MO,  START. YR  -  The  beginning  date  of  the 
simulation. 

STREAM 1 ,  STREAM2,  STREAM3,  STREAM4,  STREAMS  -  Values  used  to 
initialize  the  random  number  streams. 

TOTAL .MONTHS  -  The  number  of  months  the  simulation  runs. 

TRANSPORT. DAYS  -  The  number  of  days  required  to  transport  an 
engine  from  one  location  to  another. 

MILL  I  AMS.  CAPACITY  -  See  OCALC.  CAPACITY 


YR . CONVERSIONS . DID  -  See  DAY. CONVERSIONS. END 


Appendix  Gi  Semple  Verification  Process 


This  appendix  contains  one  example  of  the  procedure 
used  by  the  authors  to  verify  the  correct  operation  of  the 
SIMSCRIPT  model .  Page  129  shows  one  of  the  PROCESSes 
(ENTER. BASE)  from  a  modified  program  used  for  verification. 
This  PROCESS,  as  did  all  the  others,  had  verification  state¬ 
ments  inserted  in  various  places.  These  verification  state¬ 
ments  were  designed  to  monitor  appropriate  variables  (those 
that  affected  the  program's  logic  decisions)  both  before  and 
after  the  processing  of  a  specific  engine.  Examination  of 
system  variables  and  engine  attributes  at  PROCESS  initiation 
can  tell  the  modeler  what  direction  the  engine  should  take 
at  each  decision  point,  if  the  model  operates  as  planned. 
If  the  engine  actually  followed  the  correct  path  through  the 
PROCESS,  certain  system  variables  and  engine  attributes 
would  be  changed.  An  examination  of  these  variables  and 
attributes  at  the  end  of  the  PROCESS  will  reveal  if  the 
correct  changes  have  been  made.  Noting  the  correct  changes 
verifies  the  operation  of  that  portion  of  the  PROCESS. 

Prior  to  the  verification  runs,  another  modified  pro¬ 
gram  was  run  which  "captured”  and  printed  the 
ENGINE. ID. NUMBER (s)  of  those  engines  passing  through  each 
possible  "logic  path"  of  the  model .  These  engines  were 


subsequently  traced  through  the  model  by  the  verification 
program  to  determine  the  model's  correct  operation  through 
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the  logic  paths  taken  by  each  angina.  Enough  anginas  war a 
tracad  to  verify  tha  corract  oparation  o-f  all  possibla  logic 
paths  and  path  combinations. 

This  analysis  did  uncovar  several  minor  logic  arrors  in 
tha  modal .  Thasa  arrors  wara  than  corractad  and  mora  veri- 
-fication  runs  mada  on  thosa  logic  paths,  var ifying  thair 
corract  oparation. 

Tha  axampla  prasantad  tracas  angina  numbar  911  (memory 
location  186973)  as  it  is  baing  ramovad  and  raplacad  -from  an 
oparationa!  missile,  in  praparation  for  a  1 imi tad  overhaul , 
aftar  axcaading  its  warrantad  lifatima  on  basa.  Lina  numbar 
4  of  ENTER. BASE  calls  tha  routina  MI STEAK  which  axaminas  tha 
angina  to  datarmina  if  it  is  tha  ona  baing  tracad  (i.e., 
ENGINE. ID. NUMBER  -  911).  If  it  is,  MISTEAK  prints  out  a 
list  of  system  variablas  and  engine ‘at tributes  <saa  linas  1- 
46  on  paga  124)  and  a  coda  (see  lina  46  on  paga  124) 
idantifying  tha  calling  statement's  location  in  tha  program. 
This  procadura  is  rapaatad  (saa  linas  1-47  on  paga  126)  in 
lina  92  of  ENTER. BASE,  giving  tha  modalar  a  "before*  and 
■ aftar"  pictura  of  tha  system. 

As  saan  from  tha  initial  variable  list  on  paga  124, 
N. TAKE. SET  <  tha  numbar  of  anginas  in  tha  TAKE. SET)  is  equal 
to  zero.  With  proper  oparation,  linas  7-9  of  ENTER. BASE 
should  be  processed  transferring  control  to  line  29.  This 
oparation  is  verified  by  observing  tha  assignment  of  186973 
(the  mamory  location  of  FLAG)  to  ENG. OUT,  allowing  ENG. OUT 
to  trigger  routina  MISTEAK  in  lina  92  of  ENTER. BASE.  Lina  8 
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has  also  corrsctly  changed  engine  911's  CLAIM  attribute  -from 
70  (TAKEN)  to  660  (NONE).  If  the  alternate  path  in 
ENTER. BASE  (lines  11-28)  had  been  incorrectly  taken,  a  veri¬ 
fication  statement  in  line  23  would  have  printed  out,  which 
did  not  happen. 

The  initial  values  of  9il's  attributes  TEST. STATUS  (600 
-  NONE)  and  STATUS  (610  -  OVERDUE) ,  indicate  that  the  engine 
should  bypass  statements  31  and  32  and  activate  statement  34 
of  ENTER. BASE.  This  action  was  verified  by  observing  the 
activation  of  the  process  TRANSPORT  with  engine  911,  immedi¬ 
ately  after  the  end  of  the  ENTER. BASE  process.  Statement  37 
was  verified  by  observing  the  change  in  the  number  of  en¬ 
gines  listed  as  overdue  (NOUERDUE)  from  2  to  1,  and  observ¬ 
ing  no  change  (0  to  0)  in  the  number  of  broken  engines 
(NBROKEN) .  Line  47' s  operation  was  verified  by  observing 
the  change  in  911's  ALERT .MISSILE. SET  membership  from  1  (in 
the  set)  to  0  (not  in  the  set).  Finally,  line  49  was  veri¬ 
fied  by  observing  the  change  in  911's  STATUS  from  610 
(OVERDUE)  to  600  (NONE) . 
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6  REPAIRED  ENGINES  AVAILABLE,  DEPOT 1 . 

7  REPAIRED  ENGINES  AMAILABLE,  DEPOT 2 . 

8  NUMBER  OF  ENGINES  BEING  TESTED . 

9  NUMBER  OF  ENGINES  ON  ALERT . 

10  NUMBER  OF  SPARE  ENGINES  REQUIRED . 

11  NUM8ER  OF  ENGINES  IN  TAKE. SET . . 

12  NUMBER  OF  ENGINES  BROKEN . 

13  NUMBER  OF  ENGINES  OVERDUE . 

14  NUMBER  OF  LIMITED  CONVERSIONS  AMAILABLE 
13  NUMBER  OF  FULL  CONVERSIONS  AMAILABLE... 
16 

17 


.88 

.0 

.2 

.1523 

.28 

.0 

.0 

.2 

.0 

.0 


18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 


PROCESS  NUMBER . 4 

SIMULATION  TIME. . 1880 

LIFETIMES  DATED . 2818 

NUMBER  FAILED . 406 

NUMBER  DESTROYED . 18 

JTA'S  DESTROYED . 16 


ATTRIBUTES  OF  ENGINE  CALLED  ENG: 

ARRIVAL .  DATE . 1293 

CLAIM . 70 

ENGINE .  I D  .NUMBER . 911 

EXPIRATION. DATE . 1888 

LOCATION . 3 

RANK. DATE . ..1880 

SHI  PPING .  STATUS . 300 

START.  DATE . 967 

SPARE .  STATUS . . . 650 

STATUS . 610 

TEST.  STATUS . 600 

TYPE . 101 

TYPE.  SERVICE . 100 

IN  PRODUCTION  POOL? . 0 

IN  TEST. SET? . 0 

IN  REPAIRED. SET? . 0 

IN  TAKE. SET? . 0 

IN  ALERT  .MI  SSI  LE .  SET? _ _ _ 1 

DEBUG  LOCATION . 33 
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1  PROCESS  ENTER. BASE( ENG. IN , FLAG) 

2  DEFINE  ENO.  IN, ENG. OUT, FLAG  AS  INTEGER  VARIABLES 

3  CALL  MI  STEAK (ENG.  IN,  32) 

4  CALL  MI STEAK<  FLAG , 33) 

5  LET  SHI PPING . STATUS< ENG . IN)  -  NONE 

6  IF  N. TAKE. SET  -  0 

7  LET  ENG. OUT  -  FLAG 

8  LET  CLAIM(ENG.OUT)  -  NONE 

9  GO  START 

<a  A|  I.IAVP 

11  LET  CLAIM(FLAG)  «  NONE 

12  IF  FLAG  IS  NOT  IN  TAKE. SET  AND  STATUS < FLAG)  NE  NONE 

13  FILE  THIS  FLAG  IN  TAKE. SET 

14  ALWAYS 

15  FOR  EACH  ENGINE  OF  TAKE. SET,  WITH  LOCATION< ENGINE)  - 

16  LOGATI 0N< FLAG)  AND  CLAIM< ENGINE)  NE  TAKEN,  FIND  ENG. OUT  - 

17  ENGINE,  IF  FOUND 

18  IF  ENGINE. I D. NUMBER < ENG. OUT)  -  II*IUM 

19  FOR  EACH  ENGINE  OF  TAKE. SET,  UNTIL  ENGINE  -  ENG. OUT 

20  DO 

21  PRINT  1  LINE  WITH  ENGINE .  ID.  NUMBER  (ENGINE)  , 

22  LOCATION(  ENGINE)  ,  CLAIM(  ENGINE)  THUS 

23  04  EID  XXXXXXX  LOC  XXXX  CLAIM  XXXX 

24  LOOP 
23  ALWAYS 

26  GO  START 

27  AUAYS 

28  LET  ENG. OUT  «  FLAG 

29  '  START  ' 

30  IF  TEST.  STATUS(  ENG.  OUT)  -EVIP  AND  STATUS  (ENG.  OUT)  NE  BROKE 

31  CALL  SHIP  GIVING  ENG. OUT 

32  SCHEDULE  A  TEST ( ENG . OUT)  IN  TRANS. DAYS  DAYS 

33  ELSE 

34  SCHEDULE  A  TRANSPORT  (  ENG .  OUT)  NOW 

35  AUMYS 

3 6  IF  STATUS( ENG . OUT)  -  DUE 

37  SUBTRACT  1  FROM  NCVERDUE 

38  ELSE 

39  IF  STATUS( ENG . OUT)  «  BROKE 

40  SUBTRACT  1  FROM  NBROKEN 

41  ALWAYS 

42  ALWAYS 

43  IF  ENG. OUT  IS  IN  TAKE. SET 

44  REMOVE  THIS  ENG. OUT  FROM  TAKE. SET 

43  ALMYYS 

44  IF  ENG. OUT  IS  IN  ALERT. MISSILE. SET 

47  REMOVE  THIS  ENG. OUT  FROM  ALERT. MISSILE. SET 

48  ALWAYS 

49  LET  STATUS( ENG . OUT)  -  NONE 

30  LET  LOCATION(ENG.IN)  -  LOCATION (ENG. OUT) 

31  FILE  THIS  ENG. IN  IN  THE  ALERT. MISSILE. SET 

32  CALL  MISTEAK(ENG. IN,34)  CALL  MI  STEAK (ENG. OUT, 35) 

S3  END 


VARIABLES  AFTER  PROCESSING 


1  MONTH . 

2  DEPOT 1  WAIT  QUEUE . 

3  DEPOT2  WAIT  QUEUE . 

4  ENGINES  BEING  SERVICED  BY  DEPOT! . 

3  ENGINES  BEING  SERVICED  BY  DEPOT 2 . 

6  REPAIRED  ENGINES  AVAI LABLE ,  DEPOT 1 . 

7  REPAIRED  ENGINES  AVAILABLE,  DEPOT 2 . 

8  NUMBER  OF  ENGINES  BEING  TESTED . 

9  NUMBER  OF  ENGINES  ON  ALERT . 

10  NUMBER  OF  SPARE  ENGINES  REQUIRED . 

11  NUMBER  OF  ENGINES  IN  TAKE. SET . 

12  NUMBER  OF  ENGINES  BROKEN . 

13  NUMBER  OF  ENGINES  OVERDUE . 

14  NUMBER  OF  LIMITED  CONVERSIONS  AVAILABLE 

15  NUMBER  OF  FULL  CONVERSIONS  AVAILABLE. . . 


.2 

.0 

.0 

.18 

.0 

.88 

.0 

.2 

.1523 

.28 

.0 

.0 

.1 

.0 

.0 


18 

19 

PROCESS  « . . 

SIMULATION  TIME.  . . . 

. 1800 

20 

i  iPrrtMee  . 

. 2818 

21 

NUMBER 

FAILED . 

22 

NUMBER 

DESTROYED 

. 18 

23 

JTA'S 

DESTROYED . 

27  ATTRIBUTES  OF  ENGINE  CALLED  ENG* 

28  ARRIVAL .  DATE . 1293 

29  CLAIM . 600 

30  ENGINE.  ID. NUMBER . 911 

31  EXPIRATION.  DATE . 1880 

32  LOCATION . ..3 

33  RANK .  DATE . 1880 

34  SHIPPING. STATUS . 600 

33  START. DATE . 947 

36  SPARE. STATUS . 650 

37  STATUS . 600 

38  TEST. STATUS . 600 

39  TYPE . 101 

40  TYPE. SERVICE . 100 

41  IN  PRODUCTION  POOL? . 0 

42  IN  TEST. SET? . . . 0 

43  IN  REPAIRED. SET? . 0 

44  IN  TAKE. SET? . 0 

43  IN  ALERT. MISSILE. SET? . ....0 

46 

47  DEBUG  LOCATION . 33 
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